Question about asynchronous/synchronous

P

pallav

Guest
Hi,

I have a quick question about asynchronous/synchronous behavior. I
have a register file for my MIPS 32 processor. Originally, I was
modeling it using version 1 seen below. I realized the register read
access was asynchronous. Then I changed it to version 2 where the read
access is now synchronous. I'm only at simulation right now. But both
cases worked OK on my test cases. The output of the register files go
into pipeline registers for the execution stage. I think version 2 is
preferable as its fully synchrnous

My question is, are there any guidelines designers use for to
determine when to use asynchronous logic vs synchronous in logic
blocks?
Do managers enforce using flops at the input/output boundaries to
prevent timing problems that may creep up later on?

Also when running the simulations, I start with all registers as X
rather than initialized to 0. Is that a sufficient condition for
testing or should one also have them initialized to random (garbage)
values?

Thanks.

------------------------------------------------------------

module regfileV1 (/*AUTOARG*/);

input clk; // clock
input [4:0] r1, r2, w1; // source registers 1/2, destination
register 1
input [31:0] wdata; // ALU result to writeback
input wen; // enable register write
output [31:0] rd1, rd2; // data read from source registers 1/2

// A three-port register file supporting 2 reads and 1 write.
reg [31:0] regs[31:0]; // register file

// r0 is always constant 0.
assign rd1 = (r1 != 0) ? regs[r1] : 32'b0;
assign rd2 = (r2 != 0) ? regs[r2] : 32'b0;

// write on the negative edge of clk.
always @(negedge clk)
if (wen)
regs[w1] <= wdata;
endmodule // regfile

module regfileV2(/*AUTOARG*/);

input clk; // clock
input [4:0] r1, r2, w1; // source registers 1/2, destination
register 1
input [31:0] wdata; // ALU result to writeback
input wen; // enable register write
output reg [31:0] rd1, rd2; // data read from source registers
1/2

// A three-port register file supporting 2 reads and 1 write.
reg [31:0] regs[31:0]; // register file

// r0 is always constant 0.
always @(posedge clk)
begin
rd1 <= (r1 != 0) ? regs[r1] : 32'b0;
rd2 <= (r2 != 0) ? regs[r2] : 32'b0;
end

// write on the negative edge of clk.
always @(negedge clk)
if (wen)
regs[w1] <= wdata;
endmodule // regfile
 
pallav wrote:

My question is, are there any guidelines designers use for to
determine when to use asynchronous logic vs synchronous in logic
blocks?
Start by looking at both versions
on the RTL viewer of quartus or ise.
Maybe you can answer your own question.

Do managers enforce using flops at the input/output boundaries to
prevent timing problems that may creep up later on?
Managers do schedules and budgets.
I prefer registered outputs.

Also when running the simulations, I start with all registers as X
rather than initialized to 0. Is that a sufficient condition for
testing or should one also have them initialized to random (garbage)
values?
Add a reset input.

-- Mike Treseler
 
On May 21, 12:45 pm, pallav <pallavgu...@gmail.com> wrote:
Hi,

I have a quick question about asynchronous/synchronous behavior. I
have a register file for my MIPS 32  processor. Originally, I was
modeling it using version 1 seen below. I realized the register read
access was asynchronous. Then I changed it to version 2 where the read
access is now synchronous. I'm only at simulation right now. But both
cases worked OK on my test cases. The output of the register files go
into pipeline registers for the execution stage. I think version 2 is
preferable as its fully synchrnous

My question is, are there any guidelines designers use for to
determine when to use asynchronous logic vs synchronous in logic
blocks?
Do managers enforce using flops at the input/output boundaries to
prevent timing problems that may creep up later on?

Also when running the simulations, I start with all registers as X
rather than initialized to 0. Is that a sufficient condition for
testing or should one also have them initialized to random (garbage)
values?

Thanks.

In general, the choice of async vs sync rams is greatly influenced by
what ram style
is provided in the ASIC / FPGA library. For example, Xilinx block
rams are synchronous.
If you use async rams in your design, you've completely ruled out
using the block rams.

If I have a choice, I try to design using synchronous rams - if the
library has them,
great. If it doesn't, I can create them from async rams by adding
registers.

I've worked on some ASIC designs where we were required to use
synchronous rams for DFT
reasons.

I've also seen companies that have design guidelines that *strongly*
encourage designers
to have all outputs from a module registered to help simplify timing
closure.

John Providenza
 
On 2009-05-21, Mike Treseler <mtreseler@gmail.com> wrote:
Add a reset input.
This may not be a good idea. For example, in FPGAs this will mean that
it will not be possible to use efficient RAM resources (distributed RAM
or block RAMs). In ASIC you will probably not be able to find a RAM
generator which has a global reset for all flip-flops.

/Andreas
 

Welcome to EDABoard.com

Sponsor

Back
Top