Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

lpm functions and hdl

Hi all,

So I'm trying to create a (synchronous) 8-bit loadable counter, as below but for some reason this synthesizes to around 28 LE's compared to the altera LPM 11 LE version. Any idea why?

Thanks!

-Mux

module register8 (

clk,

clken,

reset_n,

data,

load,

cnt_en,

updown,

q,

q_next

);

input clk;

input clken;

input reset_n;

input [7:0] data;

input load;

input cnt_en;

input updown;

output [7:0] q, q_next;

reg [7:0] addsub;

always @(*)

if ( updown )

addsub = q - 8'd1;

else

addsub = q + 8'd1;

// asynchronous 'next' value. This is used extensively for flags

reg [7:0] q, q_next;

always @(*)

if ( load )

q_next = data;

else

begin

if ( cnt_en )

q_next = addsub;

else

q_next = q;

end

always @(posedge clk or negedge reset_n )

if ( !reset_n )

q <= 8'd0;

else if ( clken )

q <= q_next;

endmodule

12 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Frank,

    Again it is not up to us to question the OP's intention: if the OP wants a q_next, so we should give him that, no? I think the OP is now painfully aware that there is a cost for this q_next option.

    My third solution is indeed functionally equivalent to the OP's original post# 1. The difference is in the coding: I'm sure you can spot the difference, studying the RTL diagrams will help, I attach the RTL schematic for the original post.

    https://www.alteraforum.com/forum/attachment.php?attachmentid=14930

    I tried to put everything in 2 always blocks, one combinatorial, the other sequential, but that didn't work. I normally don't do Verilog, so I didn't persist.

    Regards,

    Josy
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    @josyb Yes, I'm aware there's a cost to exposing q_next and having to chose between the convenience of having the result exposed before the clock going high rather than after. Considering this module is used multiple times throughout my design I'm going to have to choose and see which where I want to take a hit. By exposing q_next I get to save additional states in my main state-machine, will has reduced the overall cost, so there's a ripple effect.. The target for my project is a MachXO2 1280 which is tight..

    With regards to having multiple 'always' blocks... I've gone through a number of 'style' iterations and kinda settled on the current one. Maybe not the nicest way but I'm sure I'll eventually come down to a more compact one.

    Thanks for the comments though! Highly appreciated!

    -Mux