Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

sverilog errors with design compiler

Status
Not open for further replies.

3wais

Member level 4
Joined
Sep 12, 2011
Messages
70
Helped
3
Reputation
6
Reaction score
3
Trophy points
1,288
Location
Alexandria,Egypt
Activity points
1,787
I'm trying to use this open source file with Design Compiler.
I analyze it as sverilog. and it gives me those warnings:
Code:
Warning:  ./src/Memory/DRAM_Controller.v:103: The construct 'declaration initial assignment' is not supported in synthesis; it is ignored. (VER-708)
Warning:  ./src/Memory/DRAM_Controller.v:104: The construct 'declaration initial assignment' is not supported in synthesis; it is ignored. (VER-708)
Warning:  ./src/Memory/DRAM_Controller.v:105: The construct 'declaration initial assignment' is not supported in synthesis; it is ignored. (VER-708)
Warning:  ./src/Memory/DRAM_Controller.v:106: The construct 'declaration initial assignment' is not supported in synthesis; it is ignored. (VER-708)
Warning:  ./src/Memory/DRAM_Controller.v:143: the undeclared symbol 'ckinb' assumed to have the default net type, which is 'wire'. (VER-936)
Warning:  ./src/Memory/DRAM_Controller.v:177: the undeclared symbol 'pllfb0' assumed to have the default net type, which is 'wire'. (VER-936)
Warning:  ./src/Memory/DRAM_Controller.v:184: the undeclared symbol 'locked' assumed to have the default net type, which is 'wire'. (VER-936)
Warning:  ./src/Memory/DRAM_Controller.v:143: The delay specification for net declaration is ignored. (VER-976)
Warning:  ./src/Memory/DRAM_Controller.v:177: The delay specification for net declaration is ignored. (VER-976)
Warning:  ./src/Memory/DRAM_Controller.v:184: The delay specification for net declaration is ignored. (VER-976)

I just ignore the warnings and go directly with the elaboration. but elaboration gives me these error and warnings:
Code:
Warning:  ./src/Memory/DRAM_Controller.v:1149: signed to unsigned assignment occurs. (VER-318)
Warning:  ./src/Memory/DRAM_Controller.v:1157: signed to unsigned assignment occurs. (VER-318)
Warning:  ./src/Memory/DRAM_Controller.v:1165: signed to unsigned assignment occurs. (VER-318)
Error:  ./src/Memory/DRAM_Controller.v:176: value of double type is not supported in synthesis. (ELAB-379)
*** Presto compilation terminated with 1 errors. ***

at line 176 there are no numbers or values. so my assumptions is this error is related to the analyze command warning at line 177.
I have no knowledge of verilog or system verilog. Can anybody help ??
 

This Verilog appears to be written specifically for a Xilinx FPGA - did you realize this?
(you can see this because it instantiates BUFG cells, and also refers to the XILINX_ISIM simulator via some of the ifdefs)

You get the "declaration initial assignment" warnings because DC is not really intended to support initial values in general-purpose flops (but FPGA flops *can* do this).
Instead, DC expects initialization to occur via async or sync reset inferrences with the "always @(...)" blocks.

The "undeclared symbol/default net type" warnings are really just informational, since instantiated cells/modules are allowed to refer to undeclared wires which will then be implicitly auto-declared, i.e. is legal Verilog.
(you could suppress that warning if you wanted to)

Signed-to-unsigned warnings are likely due to the fact that the parameters are untyped, and thus default to signed 32-bit.
(these kinds of warnings are common and can oftentimes be ignored)

It is unclear where the VER-976 warnings are coming from.
The ELAB-379 error is also a bit mysterious.
However, I suspect they are both due to the fact that "parameterized" sub-modules are being instantiated, and you did not firstly read them in as HDL code.
This is again related to the fact that this code is targeted for a Xilinx FPGA, which *would* have modules with those names (e.g. from the CORE Generator utility).

I suspect you need to re-evaluate whether this IP is suitable for an ASIC implementation, which is what you appear to be doing here.
Maybe that was the short answer?
 
  • Like
Reactions: 3wais

    3wais

    Points: 2
    Helpful Answer Positive Rating
How about trying to use the Core Generator libraries with design compiler as a workaround. would that do the trick ??
As I found in search Core Generator contains vhdl and verilog source codes.
 

You need to clarify your goal.
Are you actually targeting a Xilinx FPGA, or are you instead trying to port this IP to an ASIC std-cell design?

If targeting a Xilinx FPGA, then perhaps you should have the Xilinx 3rd-party libraries for Design Compiler.
(assuming those are even still supported, noting that Synopsys has since moved to Synplify for FPGA synthesis)

Note that I mis-spoke about the need for the Xilinx CORE Generator.
Instead, this RTL code is already referring to Xilinx Spartan-6 family *primitives* (e.g. PLL_BASE, OSERDES2, BUFG and possibly other cells).

Note also that the project summary for this Open Core IP states "Heavily optimised for Xilinx Spartan 6 FPGA family".
If you are targeting a Spartan-6 FPGA then I suggest you change to the Xilinx ISE toolset.
Otherwise, you have a lot of non-trivial work to do to modify and retarget this IP to an ASIC flow, including the need to find PLL and serdes macros that are suitable, among other details.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top