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?
Experiencing problems when moving an FPGA-based implementation to an ASIC
Started by ●February 6, 2009
Reply by ●February 6, 20092009-02-06
On 6 Feb, 10:20, mjunaidel...@gmail.com wrote:> 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 =A0 =A0 =A0 =A0 =A0 =A0 - connected to DCM > > ODDR =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- connected to DCM > > BUFG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - connected to DCM > > BUFR =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - connected to SERDE=S> > BUFIO =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- connected to SERDE=S> > 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?Yes these are all Xilinx specific blocks that you will not find in an ASIC library. However, I suspect your biggest problem is the instantiation of the DCM and SERDES blocks as you will not have these in your ASIC library either. What is your plan for those? If you use different IP for these, you will not need the cells listed above. Cheers, Jon
Reply by ●February 6, 20092009-02-06
Jon Beniston wrote:> ASIC library. However, I suspect your biggest problem is the > instantiation of the DCM and SERDES blocks as you will not have these > in your ASIC library either. What is your plan for those? If you use > different IP for these, you will not need the cells listed above.I think the biggest problem is that if you don't have a clue what you are doing the end result will not be very succesful. And with current NRE prices there is no room for trial and error. FPGA<->ASIC transitions are not push button things. Usually the whole clocking has to be redone, special IP has to be recoded or bought, testability has to be taken into consideration etc. For example depending on the serdes speed it might be doable with normal IO on ASIC. Or full custom analog+digital design is required which of course can be bought but is not in any way cheap. With FPGA many blocks are there as a default, with asic the ip availability is very vendor/fab dependent. --Kim
Reply by ●February 6, 20092009-02-06
On Fri, 6 Feb 2009 02:20:29 -0800 (PST), mjunaidelahi@gmail.com wrote:>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?As other posters have mentioned some of these cells are specific to DCM and SERDES blocks. Specifiically IDELAYCTRL & ODDR will not be needed when you get ASIC IP. The other cells are clock buffer cells and need to be removed so that ASIC CTS can implement them itself. The BUFGMUX is a standard glitchless clock mux which also needs to be implemented in behavioral RTL, used with CTS and timed properly. You need to re-architect your top level for an FPGA to ASIC port and it seems it would be better if you get some real help. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com
Reply by ●February 6, 20092009-02-06
Thank you all for informative replies. After reading your posts, I just 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 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 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 that I need this module for my ASIC implementation? Any feedback is highly appreciated.
Reply by ●February 6, 20092009-02-06
Thank you all for informative replies. After reading your posts, I just 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.
Reply by ●February 6, 20092009-02-06
On Fri, 6 Feb 2009 18:04:13 -0800 (PST), mjunaidelahi@gmail.com wrote:>But just does not make sense to me. What the use of a module whose >sole output is just left open?Sole output you can see. This is a biasing block which means there are bias current (or voltage) outputs which are shared by the needy without your awareness. Most probably if you don't instantiate it, its powerdown signals are connected active so that they don't consume power if not needed.>Or how can this module perform >calibration with an unconnected RDY port?It performs calibration by nature of its design. It's basically an analog circuit which usually includes a bipolar transistor to use the base-emittor junction as a temperature compensation mechanism.>Lastly, do you think that I >need this module for my ASIC implementation?If you have a PLL in your ASIC you already have one. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com
Reply by ●February 7, 20092009-02-07
Reply by ●February 8, 20092009-02-08
First of all you need to understand and simulate the code you are converting. I suspect it is a memory controller of some sort? Without knowing what the code does it is difficult to respond to your questions. As an FPGA and a ASIC engineer I can say you cannot expect code written for an FPGA to just work in an ASIC. Most designs use the IO functions extensively. Look at the Xilinx library guide, it gives extensive documentation on these primitives. If you look at the Unisim library from Xilinx you can see the simulation models. BUF* can be ignored but watch the skew and timing in the ASIC flow. ODDR is an stage with two flip flops and a mux. If you are producing a clock a common trick is to wire the two inputs to '1' and '0'. This gives better control of the output clock phase, and it is time aligned with other ODDR data pins - useful for talking to memories etc. Sometimes the clock to the ODDR clock forward output is 90deg phase shifted by a DCM or PLL so it is placed in the middle of the data eye. The IDELAYCTRL module is not needed. It is used in the Xilinx to calibrate the IDELAY delay lines using an external 200MHz reference clock. It only makes sense to use this block if you are also using the IDELAY blocks which are used to delay input signals by a programmable delay. /MikeJ
Reply by ●February 8, 20092009-02-08
On Feb 6, 5:20 am, mjunaidel...@gmail.com wrote:> 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?I don't remember the marketing name they use for it, but Xilinx has a line of ASICs that you can port your FPGA design to which will have all the same functional units. I expect this will not have quite as low a unit price as a full ASIC, but if your design meets their requirements, they certify that the ASIC will work to the test vectors. Certainly a good thing for someone without a lot of experience in designing ASICs. Rick
