Request Help - Non-blocking read-write problem

D

Daku

Guest
Could some Verilog guru please help ? I am using structural Verilog to
design a serial-parallel converter. The special characteristic of
incoming serial bits is that it is its own clock. That is when the
signal is high, it represents logic '1' and vice-versa. I am using non-
blocking assignment in the shift register. The problem is that
although the test harness is generating the appropriate sequence of 1s
and 0s (tested with '$display(.....)' ) the register always contains
zeros. I am using non-blocking assignment to shift the bits in the
shift register. I am not sure what exactly the problem might be. I
have attached the source for reference, and I am using Icarus Verilog
0.9.1.
Any hints, suggestions would be of immense help.

`timescale 1ns/1ns

module shiftregister(clk, pls_data_req,
txd0, txd1, txd2, txd3,
txd4, txd5, txd6, txd7);
parameter MAX = 64;
parameter BLANK64 =
64'b0000000000000000000000000000000000000000000000000000000000000000;
parameter BLANK8 = 8'b00000000;
parameter PERIOD = 1;

input clk;
input pls_data_req;
output [7:0] txd0;
output [7:0] txd1;
output [7:0] txd2;
output [7:0] txd3;
output [7:0] txd4;
output [7:0] txd5;
output [7:0] txd6;
output [7:0] txd7;

reg [7:0] txd0;
reg [7:0] txd1;
reg [7:0] txd2;
reg [7:0] txd3;
reg [7:0] txd4;
reg [7:0] txd5;
reg [7:0] txd6;
reg [7:0] txd7;

reg [63:0] q;
reg [63:0] qtmp;
integer count;

initial
begin
q = BLANK64;
qtmp = BLANK64;
txd0 = BLANK8;
txd1 = BLANK8;
txd2 = BLANK8;
txd3 = BLANK8;
txd4 = BLANK8;
txd6 = BLANK8;
txd7 = BLANK8;
count = 0;
end

always
#(PERIOD)
begin
if(count < MAX)
begin
$display("%b",pls_data_req);
q[0] <= pls_data_req;
q[1] <= q[0];
q[4] <= q[3];
q[5] <= q[4];
q[6] <= q[5];
q[7] <= q[6];
q[8] <= q[7];
q[9] <= q[8];
q[10] <= q[9];
q[11] <= q[10];
q[12] <= q[11];
q[13] <= q[12];
q[14] <= q[13];
q[15] <= q[14];
q[16] <= q[15];
q[17] <= q[16];
q[18] <= q[17];
q[19] <= q[18];
q[20] <= q[19];
q[21] <= q[20];
q[22] <= q[21];
q[23] <= q[22];
q[24] <= q[23];
q[25] <= q[24];
q[26] <= q[25];
q[27] <= q[26];
q[28] <= q[27];
q[29] <= q[28];
q[30] <= q[29];
q[31] <= q[30];
q[32] <= q[31];
q[33] <= q[32];
q[34] <= q[33];
q[35] <= q[34];
q[36] <= q[35];
q[37] <= q[36];
q[38] <= q[37];
q[39] <= q[38];
q[40] <= q[39];
q[41] <= q[40];
q[42] <= q[41];
q[43] <= q[42];
q[44] <= q[43];
q[45] <= q[44];
q[46] <= q[45];
q[47] <= q[46];
q[48] <= q[47];
q[49] <= q[48];
q[50] <= q[49];
q[51] <= q[50];
q[52] <= q[51];
q[53] <= q[52];
q[54] <= q[53];
q[55] <= q[54];
q[56] <= q[55];
q[57] <= q[56];
q[58] <= q[57];
q[59] <= q[58];
q[60] <= q[59];
q[61] <= q[60];
q[62] <= q[61];
q[63] <= q[62];
count = count + 1;
end
else if(count == MAX)
begin
$display("%b", q);
count = 0;
qtmp <= q;
q <= BLANK64;
fork
txd0 <= qtmp[7:0];
txd1 <= qtmp[15:8];
txd2 <= qtmp[23:16];
txd3 <= qtmp[31:24];
txd4 <= qtmp[39:32];
txd5 <= qtmp[47:40];
txd6 <= qtmp[55:48];
txd7 <= qtmp[63:56];
join
qtmp <= BLANK64;
/*
$display("txd0=%b txd1=%b txd2=%b txd3=%b txd4=%b txd5=%b txd6=%b
txd7=%b", txd0, txd1, txd2, txd3, txd4, txd5, txd6, txd7);*/
end
end

endmodule
 
"Daku" <dakupoto@gmail.com> wrote in message
news:1b530234-9173-423d-b47e-17207e28d323@g21g2000prn.googlegroups.com...
Could some Verilog guru please help ? I am using structural Verilog to
design a serial-parallel converter. The special characteristic of
incoming serial bits is that it is its own clock. That is when the
signal is high, it represents logic '1' and vice-versa. I am using non-
blocking assignment in the shift register. The problem is that
although the test harness is generating the appropriate sequence of 1s
and 0s (tested with '$display(.....)' ) the register always contains
zeros. I am using non-blocking assignment to shift the bits in the
shift register. I am not sure what exactly the problem might be. I
have attached the source for reference, and I am using Icarus Verilog
0.9.1.
Any hints, suggestions would be of immense help.

`timescale 1ns/1ns

module shiftregister(clk, pls_data_req,
txd0, txd1, txd2, txd3,
txd4, txd5, txd6, txd7);

[snip]
always
#(PERIOD)
begin
if(count < MAX)
begin
$display("%b",pls_data_req);
q[0] <= pls_data_req;
q[1] <= q[0];
q[4] <= q[3];
Click to expand...
Where do you set q[2] and q[3], if al all?

Where do you make clk actually do anything other
than appearing in the inputs list? I'd recommend
edge-triggering on it.

Robert Miles
 
On Aug 1, 3:35 am, Daku <dakup...@gmail.com> wrote:
Could some Verilog guru please help ? I am using structural Verilog to
design a serial-parallel converter. The special characteristic of
incoming serial bits is that it is its own clock. That is when the
signal is high, it represents logic '1' and vice-versa.
Click to expand...
Isn't this the same problem you were trying to address earlier? Your
code now has an external clock - a great first step - but you're not
using the clock internally at all.

If you read up on how a UART works, you'll note that the UART uses a
local clock to extract the data from the incoming stream within an
expected frequency range. You cannot recover an unencoded NRZ data
stream with a frequency range from DC to daylight. You need to know
what the approximate frequency range or ranges may be and design to
recover the data knowing that your bit period should be relatively
constant. Depending on the coding (or lack thereof) you may need to
reevaluate the frequency after the decode of the first bits is
attempted.

Good luck - it sounds like you don't understand the fundamentals of
the problem you're trying to solve yet. Figure that out first and you
may be on better footing.
 
On Aug 1, 9:45 pm, "Robert Miles" <mile...@usenet-news.net> wrote:

Where do you make clk actually do anything other
than appearing in the inputs list? I'd recommend
edge-triggering on it.

Robert Miles
Click to expand...
I have already tried
always @ (posedge clk)
begin
.....
end

and
always @ (negedge clk)
begin
.....
end

In both cases data is recovered, but sometimes
bits get displaced e.g., 10101110 instead of
10101011. Using $display statements in the test
harness, I know the exact sequence of bits being
sent out. I do not know what exactly is causing
this bit displacement.
 
"Daku" <dakupoto@gmail.com> wrote in message
news:ca4eb274-529b-4ad0-9835-fa9ded015390@g6g2000pro.googlegroups.com...
On Aug 1, 9:45 pm, "Robert Miles" <mile...@usenet-news.net> wrote:

Where do you make clk actually do anything other
than appearing in the inputs list? I'd recommend
edge-triggering on it.

Robert Miles

I have already tried
always @ (posedge clk)
begin
.....
end

and
always @ (negedge clk)
begin
.....
end

In both cases data is recovered, but sometimes
bits get displaced e.g., 10101110 instead of
10101011. Using $display statements in the test
harness, I know the exact sequence of bits being
sent out. I do not know what exactly is causing
this bit displacement.

Could the action of the $display statements be so
Click to expand...
close to the clock edge that sometimes one occurs
first, and sometimes the other?

Robert Miles
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top