Subject: Re: Inferring ROMs in Verilog
From: Jayaram Bhasker (jbhasker@cadence.com)
Date: Fri Jul 06 2001 - 06:46:42 PDT
Ben:
Standardizing on a set of attributes to control the structure of a synthesized
block is difficult due to the various technologies that are available.
However, I think it does make sense to at least provide a framework for
specifying such attributes - one way to do this is to describe such
attributes as part of the annex (annexes are usually for informational
purposes only).
If this makes sense, Ben, could you write up a small proposal on inferring
ROMs - it can then be further discussed in this WG?
- bhasker
> From: VhdlCohen@aol.com
> Date: Fri, 22 Jun 2001 12:24:23 EDT
> Subject: Inferring ROMs in Verilog
> To: jbhasker, vlog-synth@eda.org
> MIME-Version: 1.0
> X-Received: By mailgate2.Cadence.COM as JAA27035 at Fri Jun 22 09:25:19 2001
>
> ref: IEEE P1364.1 / D1.6, Draft Standard for Verilog® Register Transfer Level
> Synthesis
> The document DOES NOT specify HOW ROM are inferred, and which attributes if
> any can be used to infer ROMs.
> Below is information from Synplify help file that addresses this issue. I
> recommend that we add a recommendation and possibly attributes to infer ROMs.
> ---
> //from Synplify help 3/13/01
> "Generally, Synplify infers ROMs from HDL source code that uses CASE
> statements, or equivalent IF statements, to make 16 or more signal
> assignments using constant values (words). The constants must all be the same
> width.
>
> Verilog Example:
> module rom2(z, a);
> output [3:0] z;
> input [4:0] a;
> reg [3:0] z ;
> always @(a)
> begin
> case (a)
> 5'b00000: z = 4'b1011;
> 5'b00001: z = 4'b0001;
> 5'b00100: z = 4'b0011;
> 5'b00110: z = 4'b0010;
> 5'b00111: z = 4'b1110;
> 5'b01001: z = 4'b0111;
> 5'b01010: z = 4'b0101;
> 5'b01101: z = 4'b0100;
> 5'b10000: z = 4'b1100;
> 5'b10001: z = 4'b1101;
> 5'b10010: z = 4'b1111;
> 5'b10011: z = 4'b1110;
> 5'b11000: z = 4'b1010;
> 5'b11010: z = 4'b1011;
> 5'b11110: z = 4'b1001;
> 5'b11111: z = 4'b1000;
> default: z = 4'b0000;
> endcase
> end
> endmodule
>
> ...
> Attribute; Altera (APEX, ACEX families and FLEX10K). You can describe a ROM
> structure in RTL code using a CASE statement. By applying the syn_romstyle
> attribute to the signal output value, you can control if the ROM structure is
> implemented as discrete logic or as an ESB block for APEX or EAB blocks for
> FLEX and ACEX.
> By default, Synplify and Synplify Pro implement small ROMs (less than seven
> address bits) as logic, and large ROMs (seven or more address bits) as ESBs
> for APEX and EABs for FLEX and ACEX.
>
> You can globally disable automatic use of ESBs/EABs for inferred ROMs by
> setting altera_auto_use_eab = 0 (FLEX and ACEX) or altera_auto_use_esb = 0
> (APEX).
> Setting syn_romstyle=logic in an APEX, ACEX, or FLEX device forces an
> implementation using discrete logic primitives. Setting
> syn_romstyle=block_rom forces an ESB implementation when targeting APEX
> devices, and an EAB implementation when targeting FLEX and ACEX devices.
>
> .sdc File Syntax and Example
>
> define_attribute {rom_primitive} syn_romstyle {logic|block_rom}
>
> For example:
>
> define_attribute {z_20[3:0]} syn_romstyle {block_rom}
>
> Verilog Syntax and Example
>
> object /* synthesis syn_romstyle = "logic|block_rom" */ ;
>
> The following example shows you how to use the syn_romstyle attribute to
> implement a ROM structure as block_rom, which forces an ESB/EAB
> implementation.
>
> reg [3:0] z /* synthesis syn_romstyle = "block_rom" */;
>
> The following example shows you how to use the syn_romstyle attribute to
> implement a ROM structure as logic, which forces an implementation using
> discrete logic primitives.
>
> reg [8:0] z /* synthesis syn_romstyle = "logic" */;
>
> ..
> nferring ROMs Examples
>
> The following examples show you how to infer a ROM.
>
> Verilog Example
>
> /* Sparsely populated ROM */
> module rom2(z, a);
> output [3:0] z;
> input [4:0] a;
> reg [3:0] z /* synthesis syn_romstyle = "block_rom" */;
> always @(a) begin
> case (a)
> 5'b00000: z = 4'b1011;
> 5'b00001: z = 4'b0001;
> 5'b00100: z = 4'b0011;
> 5'b00110: z = 4'b0010;
> 5'b00111: z = 4'b1110;
> 5'b01001: z = 4'b0111;
> 5'b01010: z = 4'b0101;
> 5'b01101: z = 4'b0100;
> 5'b10000: z = 4'b1100;
> 5'b10001: z = 4'b1101;
> 5'b10010: z = 4'b1111;
> 5'b10011: z = 4'b1110;
> 5'b11000: z = 4'b1010;
> 5'b11010: z = 4'b1011;
> 5'b11110: z = 4'b1001;
> 5'b11111: z = 4'b1000;
> default: z = 4'b0000;
> endcase
> end
> endmodule
>
>
>
> ------------------------------------------------------------------------------
>
> --------------------------------------
> Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
> http://www.vhdlcohen.com/ vhdlcohen@aol.com
> Author of following textbooks:
> * Component Design by Example ... a Step-by-Step Process Using
> VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1
> * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
> * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
> ------------------------------------------------------------------------------
>
> --------------------------------------
J. Bhasker
Cadence Design Systems
7535 Windsor Drive, Suite A200, Allentown, PA 18195
610.398.6312, 610.530.7985 (fax), jbhasker@cadence.com
This archive was generated by hypermail 2b28 : Fri Jul 06 2001 - 07:13:37 PDT