need a cheap student edition FPGA

[John_H]

<paulw@mmail.ath.cx> wrote in message
news:1112136777.540743.317340@g14g2000cwa.googlegroups.com...

<snip>

What would happed if using regs changed earlier? synch and simulation
mismatch? Thanks.

Don't use regs changed earlier !!

For synthesizeable logic, non-blocking operators where a reg is assigned in
one always block is the way to go.
In simulation where synthesis isn't expected, changing a reg at discrete
points in time is great - just don't try to change the reg in multiple
blocks at the same time.

 

[Ray Dong]

"Johnson Zhuang" <johnsonzhuangsh@yahoo.com.cn> wrote in news:cii1n7$gcf$1
@news.tamu.edu:
I have written one, contact me!
dongrj@hotmail.com

 

[Jonathan Bromley]

On 30 Mar 2005 01:50:18 -0800, paulw@mmail.ath.cx wrote:

Let's make this easy for me.

At present, you seem to be making it quite hard for yourself

What if I have only one always block in the enitre module.
Is will no longer be a problem then? Ie. I can use regs
changed earlier, so long as I don't change the same reg twice.

As someone's already said, simulation and synthesis WILL match
because that's what synthesis tools do - they build logic with
the same behaviour as the simulation behaviour of your Verilog.
Sometimes you can write Verilog for which the synth tool can't
build equivalent logic, and it will then complain to you.

HOWEVER, it is very easy to make race conditions in Verilog.
These race conditions have a direct equivalent in hardware:
they correspond to hold time violations. Simulation will
show you just one of the possible outcomes of the race
condition; it may or may not be the same outcome as you get
in the synthesised hardware. This, of course, is a Bad Thing.
It is not a simulation/synthesis mismatch; it is an
indeterminacy in the Verilog description, and the
indeterminate results that you see in simulation may differ
from the indeterminate results you see in hardware.

Avoiding these race conditions is almost as easy as making them.
The golden rule for synthesisable code:

In a clocked "always", use NONBLOCKING assignment to write
to any variable whose value is used outside the "always".

Elaborating on that golden rule, with a few cases that
sometimes cause confusion:

Variables used only within the "always" can be written
with either blocking or nonblocking assignment (but not
a mixture of the two!) as you please - the effects will
be different, but in both cases the effects will be
entirely predictable and there will be neither race
conditions nor simulation/synthesis mismatches.

A variable whose value goes to an output port of the
module is, of course, a 'variable whose value is used
outside the "always"'. So any such variable MUST be
written using nonblocking assignment.

Combinational "always" blocks should use blocking
assignment in any case.

Now, let's go back to your "using a reg that was changed
earlier". It's probably best to look at a specific
example....

// primary inputs: clk, a, b, c
// local variables: reg v
// primary output: reg r
//
always @(posedge clk) begin
v = a & b;
if (c) v = ~v;
r <= v;
end

I've changed "v" twice. This is OK! "v" is a temporary
variable representing intermediate stages in a calculation.
In the synthesised hardware there will be two quite separate
places corresponding to "v": the output of the AND gate for
v = a & b;
and the output of an XOR gate for
if (c) v = ~v;
The result is a single flip-flop "r" whose D input is fed with
the Boolean expression ((a & b) ^ c).

Note, however, that I am obliged to use a NONBLOCKING assignment
to "r" because it's a primary output that will be used in
other parts of the code. No excuses. Don't even think about
making blocking assignment to "r".

As a thought-experiment (and for synthesis and simulation too)
consider how my "always" block would behave if I were to use
nonblocking assignment throughout. It is still a completely
valid piece of code (although it probably needs a reset now):

always @(posedge clk) begin
v <= a & b;
if (c) v <= ~v;
r <= v;
end

Now we have two flip-flops "v" and "r". The D input of "v"
is fed with the expression

((a & b) & ~c) | (c & ~v)

Note that the flip-flop's output is used in this expression;
that's OK of course. The D input of "r" is connected to the
output of flip-flop "v".

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just don't EVER write to primary outputs of a clocked "always"
using blocking assignment. Never. Not even on feast-days.
Not even if you think your "always" block is the only one in
the world - perhaps it is today, but it won't be tomorrow.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[glen herrmannsfeldt]

John_H wrote:

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:d29vdv$ttq$1@gnus01.u.washington.edu...

paulw@mmail.ath.cx wrote:

snip

You should also not change any variables used later in the same
block.

a=b+c;
d=a+b;

Why not?
Blocking and non-blocking operators should both be synthesizeable.
Simulation and synthesis results should match.

It's *typical* for the designer to produce always blocks without the
blocking operator so everything has a previous-state/next-state relationship
at the clock edge. When blocking operators are used in this (@posedge clk)
blocks, the results tend not to be as expected, at least to the engineer
debugging the code later.

I think you are right, but it will at least be confusing to
people. I pretty much always use non-blocking assignment, but
still put the statements in order, such that later ones don't
use regs changed earlier. Partly that comes from writing C code
with similar function.

-- glen

 

[Jonathan Bromley]

On 30 Mar 2005 05:42:09 -0800, paulw@mmail.ath.cx wrote:

Most of my circuit will be
lots of temporary regs with very little input and output. So all I need
to take care are when interfacing input and output.

Gulp....

When you say "temporary regs", do you mean internal flip-flops that
hold some internal state or result of a calculation; or do you mean
"reg" variables in Verilog? There's an important distinction.

A Verilog "reg" is just the simulator's name for a variable; indeed,
in the Verilog-2001 standard, the generic name "register" was dropped
in favour of the more appropriate "variable", although of course the
language keyword "reg" still stands.

Depending on how you use a "reg" in a clocked "always", it may
turn out to be one of three subtly different things...

(1) a reg assigned-to using nonblocking assignment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
will unquestionably synthesise to a flip-flop. You can assign
to such a reg using <= as many times as you wish in the
"always" block. The LAST of these assignments to be executed,
and ONLY the last, is the one that takes effect. Whenever you
use the name of the reg in any other context (e.g. on the
right-hand side of an assignment), the value you get is the
value held in the flip-flop just BEFORE the clock edge,
unaffected by any nonblocking assignments. After all, they're
nonblocking and therefore they haven't taken effect yet

(2) a reg assigned-to using blocking assignment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gets its new value immediately on assignment, and this new
value is then available for use later in the code. You
can make as many blocking (=) assignments as you wish
to such a variable. Immediately after each assignment,
on the next line of Verilog code, you can see the new
value in the reg. Such a reg may or may not synthesise
to a flip-flop; there are two cases:

(2a) You get a flip-flop....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if the reg's value is used before it is written. In such a
case, the value you see is the value "left over" from the
previous clock cycle. This value must, of course, have
been held in a flip-flop. This is a convenient way to
get "local" variables that are held in registers between
clock edges. If you subsequently make more than one
blocking assignment to this reg, then only the last of
those assignments determines the value held in the flip-
flop. Earlier assignments will synthesise to intermediate
stages in the combinational logic.

(2b) You DON'T get a flip-flop....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
if the reg is written with a new value before its value is
used. In this case, although simulation says that the reg
has held its old value since the previous clock, that value
is trashed before anyone tries to use it - so the synth
tool knows that it can safely be thrown away, and no
flip-flop is created. This is a convenient way to break
up complicated calculations, or to identify common sub-
expressions, in the combinational logic that drives
other registers. Typically, each assignment to the reg
will represent a different place in the combinational
logic.

All three of these scenarios are perfectly valid for
synthesis, with all the synthesis tools I use. However,
I am aware of one synth tool that will not, under any
circumstances, allow a mixture of blocking and nonblocking
assignments in the same always block; that's crazy.

As I said in the previous post, you must NEVER allow any
reg that's written using blocking assignment to leak
outside the always block that writes to it. A very
convenient way to guarantee this is to declare such regs
locally within a labelled begin...end. Here's a 2-stage
shift register; the first stage "f" is a local register,
the second stage "q" is a primary output and therefore
must be assigned using <=. This is not a very sensible
way to describe a shift register, but I hope it illustrates
the point I'm trying to make.

module SR2 (clk, d, q);
input clk, d;
output q;
reg q;

always @(posedge clk) begin : ShiftReg
reg f; // declared locally inside named begin...end

q <= f; // read "q" before writing it,
// so it will be a FF
f = d;
// Note: at this point, reg "f" contains the value that
// the first-stage FF will hold JUST AFTER the clock
// edge. It is, in effect, the next-state value of "f".
// We don't use it in this code, but it can be very
// useful in more complicated situations.
end // ShiftReg

// Outside the "always" we can make use of "q", but
// the value of "f" is hidden because it's declared
// inside the begin...end.
endmodule // SR2

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hope this helps.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[plugh]

On Wed, 30 Mar 2005 17:09:37 +0100, Jonathan Bromley wrote:

On 30 Mar 2005 05:42:09 -0800, paulw@mmail.ath.cx wrote:
Most of my circuit will be
lots of temporary regs with very little input and output. So all I need
to take care are when interfacing input and output.

Gulp....

Gulp indeed. Especially if you're investing $1/2M or more to see if your
ASIC will work right.

I prefer to 'program stupid' as some people say. I follow some very
simple self-discipline to make sure I don't violate the rules as explained
by John_H and Jonathan B. previously in this thread:

In code that is to be synthesized, I never use blocking ('=') assigns
inside 'always' blocks. Then I never have to worry that something gets
synthesized in an unexpected way (like with a race condition built in).
Prior to sign-off, I make a quick pass through all the code looking for
places that might have a '=' where it should be a '<=' and vice-versa
('grep' is very convenient here).

So what about intermediate results? How do I reduce a complex equation
down to something easily understandable? Simple: move it outside the
'always' block. Instead of:

always @(posedge CLK or negedge RESET_)
if (~RESET_)
x <= 0;
else
begin
tmp = a & b;
x <= tmp | c;
end

use:

wire tmp = a & b;
always @(posedge CLK or negedge RESET_)
if (~RESET_)
x <= 0;
else
x <= tmp | c;

Same idea, but I *know* without having to spend any brain power that tmp
is combinatorial, and I *know* that x is a flip-flop. And most
importantly, I *know* that the synthesizer will agree with me.

Of course, tmp needs a nice descriptive name so you can read what your
code is doing instead of having to figure it out each time you look at it.

The end result should be the same either way. The down-side is a
slight loss of 'locality of reference', but I'll gladly sacrifice that in
exchange for my own peace of mind (with respect to those large NRE costs).

And tyrant that I am, I make my team do it too.

Actually, it's even more beneficial when several people are working on the
project: if any of my guys sees a '=' in an 'always' blocks, they know
it's a typo and they'll fix it without having to ask about it.

Regards,
plugh

 

[Bob Perlman]

Hi -

A couple of comments. First, thanks to Jonathan for excellent
write-ups that belong in a FAQ somewhere, given the frequency with
which this question arises.

And I have to agree with plugh that choosing a fairly simple set of
coding rules can be extremely helpful in ensuring correctness (or as I
used to say about 25 years ago, Clever Kills). I usually code
combinatorial logic with continuous assignments, or put the
combinatorial stuff on the right-hand side of a non-blocking
assignment in a clocked always block. And I will on occasion put
combinatorial logic in a non-clocked always block with blocking
assignments. But a clocked always block will consist of non-blocking
assignments only. Overly restrictive? Perhaps. I'm not saying you
can't be more creative than this, but these simple restrictions make
the code very easy to check.

I forget who said it, but someone pointed out that if finding bugs is
harder than coding, then when we write the cleverest code we can, we
may not be smart enough to debug it.

Bob Perlman
Cambrian Design Works



On Wed, 30 Mar 2005 15:06:21 -0800, plugh
<plugh@hello--excise-this--six.com> wrote:

On Wed, 30 Mar 2005 17:09:37 +0100, Jonathan Bromley wrote:

On 30 Mar 2005 05:42:09 -0800, paulw@mmail.ath.cx wrote:
Most of my circuit will be
lots of temporary regs with very little input and output. So all I need
to take care are when interfacing input and output.

Gulp....

Gulp indeed. Especially if you're investing $1/2M or more to see if your
ASIC will work right.

I prefer to 'program stupid' as some people say. I follow some very
simple self-discipline to make sure I don't violate the rules as explained
by John_H and Jonathan B. previously in this thread:

In code that is to be synthesized, I never use blocking ('=') assigns
inside 'always' blocks. Then I never have to worry that something gets
synthesized in an unexpected way (like with a race condition built in).
Prior to sign-off, I make a quick pass through all the code looking for
places that might have a '=' where it should be a '<=' and vice-versa
('grep' is very convenient here).

So what about intermediate results? How do I reduce a complex equation
down to something easily understandable? Simple: move it outside the
'always' block. Instead of:

always @(posedge CLK or negedge RESET_)
if (~RESET_)
x <= 0;
else
begin
tmp = a & b;
x <= tmp | c;
end

use:

wire tmp = a & b;
always @(posedge CLK or negedge RESET_)
if (~RESET_)
x <= 0;
else
x <= tmp | c;

Same idea, but I *know* without having to spend any brain power that tmp
is combinatorial, and I *know* that x is a flip-flop. And most
importantly, I *know* that the synthesizer will agree with me.

Of course, tmp needs a nice descriptive name so you can read what your
code is doing instead of having to figure it out each time you look at it.

The end result should be the same either way. The down-side is a
slight loss of 'locality of reference', but I'll gladly sacrifice that in
exchange for my own peace of mind (with respect to those large NRE costs).

And tyrant that I am, I make my team do it too.

Actually, it's even more beneficial when several people are working on the
project: if any of my guys sees a '=' in an 'always' blocks, they know
it's a typo and they'll fix it without having to ask about it.

Regards,
plugh

 

[tooluser]

I am writing a verilog testbench and using the new file IO statements
defined in Verilog 2001. The testbench with the new file IO statement
works great with modelsim 6.0a but it did not work with NC-Verilog
5.10. The following is part of the design that NC-Verilog is having
problems:

My experience with "C-style file I/O" was painful, and taught me not
to expect things to work as expected. Each tool (VCS, Modelsim, NCsim)
has a different set of bugs.

In VCS's case, I found that $fscanf( ..., "%d", my_integer ) doesn't
handle negative base10 numbers correctly. (Modelsim and NC-Verilog
will read signed base10 integers from a text-file without problem.)

I also tried to write out binary (non-ASCII) files using $fputc.
(Basically, I passed $fputc an ASCII-code in the form of a reg [7:0]) --
NC-Verilog and VCS correctly wrote out binary files, but Modelsim
wrote out jibberish. But I'm probably stepping outside the
boundary of defined behavior for $fputc.

 

[Jonathan Bromley]

On Thu, 31 Mar 2005 03:07:37 GMT, Bob Perlman
<bobsrefusebin@hotmail.com> wrote:

A couple of comments. First, thanks to Jonathan for excellent
write-ups that belong in a FAQ somewhere, given the frequency with
which this question arises.

It's been done - Cliff Cummings's well-known papers on
nonblocking assignments cover most of the ground, although
he's opposed to the use of blocking assignment to temporaries.

And I have to agree with plugh that choosing a fairly simple set of
coding rules can be extremely helpful in ensuring correctness (or as I
used to say about 25 years ago, Clever Kills).

Agreed. But "Clever" is often the same as "Stuff I'm not
familiar with", and sometimes it pays to get familiar so
that it doesn't look so clever in the future. Hence my
rather long-winded and overly didactic rants.

I usually code
combinatorial logic with continuous assignments, or put the
combinatorial stuff on the right-hand side of a non-blocking
assignment in a clocked always block. And I will on occasion put
combinatorial logic in a non-clocked always block with blocking
assignments. But a clocked always block will consist of non-blocking
assignments only.

Many folks do this; the old OpenMore coding standard mandates it;
it works especially well for some types of design where there's an
intimate interaction between a data path and a control block, each
of which is so complicated that they need to be coded separately.
I have just one reservation about it - see below.

Overly restrictive? Perhaps. I'm not saying you
can't be more creative than this, but these simple restrictions make
the code very easy to check.

I have no problem at all with "restrictive" per se. My issue is
with the proliferation of module-global signals that this style
creates. Using blocking assigns to *locally declared* variables,
stuff that you don't need to see outside the clocked block
of logic (such as next-state values) can be safely hidden
inside the always block. No risk of accidental re-use of the
same name elsewhere in a big complicated module, and the
localised variable can't go outside the block and hence
cannot be responsible for races. You can still see them
from your verification code using hierarchical names, but
synth tools won't process those.

Blocking assigns to temporaries declared at the module level
are an open invitation to the bugs, of course. Avoid at
all costs.

SystemVerilog's nested modules provide a way to hide locals
and still retain your chosen coding style, so this may
ultimately be the very best way to proceed.

I forget who said it, but someone pointed out that if finding bugs is
harder than coding, then when we write the cleverest code we can, we
may not be smart enough to debug it.

Bob, I know I don't need to say this to you, but.... if we employ
our cleverness with the aim of creating clear-headed, well-
localised code, then we are much less likely to introduce bugs
in the first place and - if we do it right - we make it *easier*
to debug. Your paradox is a nice insight, but it runs the
dangerous risk of confusing "clever" with "ingeniously obfuscated".

Thanks for the thought-provoking comments.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[John Penton]

thomasc wrote:

The three files at the bottom are designed for the following purposes:
rx_buffer.v : 105 8-bit registers
rx_SB.v : 15 8-bit registers
tb_rx_SB.v : testbench

What I am trying to implement is to store 15 byte values from
rx_buffer to rx_SB register. But the value at particular clock cyle
is stored in rx_SB one clock cycle later (I thought it may be because
rx_SB is reg.) What is intended is to, as soon as index is updated,
store the corresponding value from rx_buffer to rx_SB. Otherwise, the
value for a particular index will be available the cycle after the
index is presented.

What you say you want does not sound like a synchronous design. If you are
storing data in flip-flops (anything updated @(posedge clk)) then they will
naturally update on the next rising edge after the address and data are
presented to them, so that the newly written data is available in the next
clock cycle. This is normal. Have I understood you correctly?

I have put some comments in with your code anyway.

Please let me know how I can correct this problem.
SB changes from 1 to 7 and rx_count changes from 0 to 14.
Thanks much in advance!

thomasc

///////
//rx_SB
///////
module rx_SB(SB,en_RS);

input [7:0] SB;

input en_RS;

I have swapped the two inputs round to match the argument list, just to make
things clear since you are using positional association when you
instantiated the module.

wire clk_main;
wire [7:0] din;
wire [7:0] index;
reg [7:0] rx_count;
reg [7:0] rx_SB [0:14];

clkGen_main CGM (clk_main);
rx_buffer RB (.dout(din),.addr(index));

assign index= (SB-1) ? ((SB*14)+1)+rx_count : (SB*14)+rx_count;

Warning, (SB-1) is an 8-bit bus, but it is being used in a boolean context.
Futher, you are assigning what is potentially a 13-bit value into an 8-bit
bus. You will lose significant bits in the general case.

always @(posedge clk_main) begin: read_SB
if (en_RS) begin
rx_count=8'h00;

A blocking assignment in a sequential block can be dangerous.

disable read_SB;
end

if ((rx_count>15)) disable read_SB;

rx_SB[rx_count]<=din;
rx_count<=rx_count+1;
end

Personally I would use if...else constructs rather than disable (to make it
read more easily), like this:

always @(...
begin
if (en_RS) begin
rx_count <= 8'h00;
end
else if (rx_count<16) begin
rx_SB[rx_count] <= din;
rx_count <= rx_count+1;
end
end

endmodule

///////////
//rx_buffer
///////////
module rx_buffer(dout,addr);

parameter SB_MAX = 7,
PARITY_DEPTH = 4,
TX_DEPTH = 11,
SYNC_BLOCK_DEPTH = TX_DEPTH+PARITY_DEPTH;

input [7:0] addr;
output [7:0] dout;

reg [7:0] rx_buffer [0SB_MAX*SYNC_BLOCK_DEPTH)-1] = {
8'h01,8'h02,8'h04,8'h08,8'h03,8'h06,8'h0C,8'h0B,8'h05,8'h0A,8'h17,8'h00,8'h00,8'h00,8'h00,
8'hA2,8'hA3,8'hA5,8'hA9,8'hA4,8'hA7,8'hAD,8'hAC,8'hA6,8'hAB,8'h28,8'h00,8'h00,8'h00,8'h00,
8'hB3,8'hB4,8'hB6,8'hBA,8'hB5,8'hB8,8'hBE,8'hBD,8'hB7,8'hBC,8'h39,8'h00,8'h00,8'h00,8'h00,
8'hC4,8'hC5,8'hC7,8'hCB,8'hC6,8'hC9,8'hCF,8'hCE,8'hC8,8'hCD,8'h4A,8'h00,8'h00,8'h00,8'h00,
8'hD5,8'hD6,8'hD7,8'hDB,8'hD6,8'hD9,8'hDF,8'hDE,8'hD8,8'hCD,8'h4A,8'h00,8'h00,8'h00,8'h00,
8'hE6,8'hE7,8'hE7,8'hEB,8'hE6,8'hE9,8'hEF,8'hEE,8'hE8,8'hCD,8'h4A,8'h00,8'h00,8'h00,8'h00,
8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00,8'h00};

assign dout = rx_buffer[addr];

endmodule

//////////
//tb_rx_SB
//////////
`timescale 1ns/1ns
module tb_rx_SB;

reg en_RS;
reg [7:0] SB;

rx_SB RS (
.SB (SB),

.en_RS (en_RS)
);

initial begin
SB=8'd2;
en_RS=0;
#25;
en_RS=1;
#100;
en_RS=0;
end

endmodule

--
John Penton, posting as an individual unless specifically indicated
otherwise.

 

[Jan Decaluwe]

Jonathan Bromley wrote:

always @(posedge clk) begin : ShiftReg
reg f; // declared locally inside named begin...end

q <= f; // read "q" before writing it,
^

correction: "f"

// so it will be a FF
f = d;
// Note: at this point, reg "f" contains the value that
// the first-stage FF will hold JUST AFTER the clock
// edge. It is, in effect, the next-state value of "f".
// We don't use it in this code, but it can be very
// useful in more complicated situations.
end // ShiftReg

// Outside the "always" we can make use of "q", but
// the value of "f" is hidden because it's declared
// inside the begin...end.
endmodule // SR2

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hope this helps.

--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Using Python as a hardware description language:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

 

[Bob Perlman]

On Thu, 31 Mar 2005 09:25:21 +0100, Jonathan Bromley
<jonathan.bromley@doulos.com> wrote:

Good stuff snipped...

Bob, I know I don't need to say this to you, but.... if we employ
our cleverness with the aim of creating clear-headed, well-
localised code, then we are much less likely to introduce bugs
in the first place and - if we do it right - we make it *easier*
to debug. Your paradox is a nice insight, but it runs the
dangerous risk of confusing "clever" with "ingeniously obfuscated".

Good point. There's cleverness in the service of better design, and
cleverness in the service, of, well, "Hey, look what I can do." Only
with experience do we learn to tell the difference.

Take care,
Bob Perlman
Cambrian Design Works

 

[Jan Decaluwe]

plugh wrote:

On Wed, 30 Mar 2005 17:09:37 +0100, Jonathan Bromley wrote:


On 30 Mar 2005 05:42:09 -0800, paulw@mmail.ath.cx wrote:

Most of my circuit will be
lots of temporary regs with very little input and output. So all I need
to take care are when interfacing input and output.

Gulp....


Gulp indeed. Especially if you're investing $1/2M or more to see if your
ASIC will work right.

I prefer to 'program stupid' as some people say. I follow some very
simple self-discipline to make sure I don't violate the rules as explained
by John_H and Jonathan B. previously in this thread:

In code that is to be synthesized, I never use blocking ('=') assigns
inside 'always' blocks. Then I never have to worry that something gets
synthesized in an unexpected way (like with a race condition built in).
Prior to sign-off, I make a quick pass through all the code looking for
places that might have a '=' where it should be a '<=' and vice-versa
('grep' is very convenient here).

I wonder where you found this "rule" in Jonathan's post. In fact, he
calls this restrictive coding style "crazy". To summarize: he argues,
quite correctly, that blocking assigns are just fine, also for synthesis,
and even (oh heresy!) to infer flip-flops from them. Just keep those
regs local in clocked always blocks, that's all.

You're not to blame of course, because you are in the good company of
the mainstream Verilog gurus. It's just what over-exposure to Verilog
does to one's mind. Here's the reason: Verilog doesn't make the distinction
between such entirely different concepts of a variable and, ahem, a signal.
Because of this major design flaw, the confusion will go on forever.
And the opportunities to write better, more beautiful code will
continue to be missed.

Regards,

Jan

--
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
Using Python as a hardware description language:
http://jandecaluwe.com/Tools/MyHDL/Overview.html

 

[Jonathan Bromley]

On Fri, 01 Apr 2005 10:26:28 +0200, Jan Decaluwe <jan@jandecaluwe.com>
wrote:

plugh wrote:
[...]
I prefer to 'program stupid' as some people say. I follow some very
simple self-discipline to make sure I don't violate the rules as explained
by John_H and Jonathan B. previously in this thread:

In code that is to be synthesized, I never use blocking ('=') assigns
inside 'always' blocks. Then I never have to worry that something gets
synthesized in an unexpected way (like with a race condition built in).
Prior to sign-off, I make a quick pass through all the code looking for
places that might have a '=' where it should be a '<=' and vice-versa
('grep' is very convenient here).

I wonder where you found this "rule" in Jonathan's post.

In fairness, Jan, I don't think plugh either found it or intended
to suggest I wrote it; but instead, is saying "here's a simple
restrictive style that allows me to be sure I'm not breaking
the rules, without my having to worry too much".

In fact, he
[meaning me, Jonathan]
calls this restrictive coding style "crazy".

Ahem, no, I didn't; I said that it's crazy for a tool to enforce
it (and I stick by that statement, even though it may lose me
a friend or two). If individuals choose to limit their coding
style to an easily understood subset of what's possible and
safe, that's fine by me.

You're not to blame of course, because you are in the good company of
the mainstream Verilog gurus. It's just what over-exposure to Verilog
does to one's mind. Here's the reason: Verilog doesn't make the distinction
between such entirely different concepts of a variable and, ahem, a signal.

I didn't say that... not in public, anyway

Because of this major design flaw, the confusion will go on forever.
And the opportunities to write better, more beautiful code will
continue to be missed.

I think I agree; but I have to keep reminding myself that
VHDL has some pretty significant shortcomings too.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[m]

On 1 Apr 2005 18:47:30 -0800, perltcl@yahoo.com wrote:

Hi

Is there some trick that your can do so that when assigning 2 inverter
in series, that they won't get "optimised" away. I don't know why I
need this, but it would be cool to do. Thanks. I know this not really
about verilog, but it would be great if I can do it using verilog
without using schematics.

yes there is and yes you're right this is not about verilog. in your
synthesis tool, there should be documentation about a macro, command
etc which effectively sets a "dont use", "dont modify", "preserve"
etc. type property on the inverters in question.

 

[info_]

perltcl@yahoo.com wrote:

Hi

Is there some trick that your can do so that when assigning 2 inverter
in series, that they won't get "optimised" away. I don't know why I
need this, but it would be cool to do. Thanks. I know this not really
about verilog, but it would be great if I can do it using verilog
without using schematics.

Sorry, but this "smells bad" !
Does it means you count on delays by doing this ?
In an FPGA ?
There is no inverter in an FPGA, there are LUTs, and interconnects.

I would strongly encourage you in thinking twice before
counting on delays that you would infer by attempting to
preserve inverters in a HDL description.
There are many processes which will try to get rid of them at
each step towards the final bitstream...
And I have doubts about the reliability of what you may get.

In other words, I suspect your request relates to asynchronous
design, and this smells bad (at least through HDL synthesis
and FPGA targets).

I hope I am wrong ;-)

Bert

 

[Jason Zheng]

perltcl@yahoo.com wrote:

Hi

Is there some trick that your can do so that when assigning 2 inverter
in series, that they won't get "optimised" away. I don't know why I
need this, but it would be cool to do. Thanks. I know this not really
about verilog, but it would be great if I can do it using verilog
without using schematics.

For synplify, I think you need to use "syn_keep" directive on the output

net to preserve the seemingly redundant logic. There might be use for
this on some specialty circuits, such as some interfacing logic between
two clock domains. But other than that, I don't know why you would need it.

-jz

 

[Vladislav Muravin]

Williams,

By default, an IBUFG & BUFG are instantiated, but if you specify something
like:

wire dcmclkout;
// synthesis attribute clock_signal of dcmclkout is true
// synthesis attribute clock_buffer of dcmclkout is none

the synthesis tool will not issue a clock buffer placement.

i usually instantiate IBUFG & BUFG, for safety.
hope this helps.

Vladislav

"williams" <stud_lang_jap@yahoo.com> wrote in message
news:d02ff4ca.0504040358.600e560e@posting.google.com...

Hello Guys,
I had a doubt about the IBUFG and BUFG in xilinx.
1.I have connected clock from oscillator to CLKG IO of the Xilinx. In
this case is it required to instantiate the IBUFG inside my code
also?.
2. The DCM output is already BUFG i think and so is it required to
BUFG again in my code?

Thanks and regards
Williams

 

[Dan Notestein]

Another alternative for doing this besides GTK is GigaWave Viewer.
It can view both real-valued analog signals and digital bus values
as analog signals. It's a commercial package, costs $1K. It's available
for download from http://www.syncad.com

best regards,

Dan Notestein
SynaptiCAD

bybell@rocketmail.com wrote in news:1112633969.413828.250480
@z14g2000cwz.googlegroups.com:

RaphFrk wrote:

I am trying to use GTKwave to look at a vcd file. I have a bus that
I
want to look at like an analog waveform. In this instance, it is a
bus of type real. However, the same issue would apply if it was say
a
10 bit bus which I want to look at as a waveform.

One bit busses show up as a waveform, is there a setting a need to
click to get it to change a bus into a waveform ?

The 2.0 series has such a feature if I remember correctly; the 1.3
series doesn't. I don't know what if any analog specific features 2.0
would have like zero crossing mapping, derivatives, etc. Whatever the
case is, as far as I know 2.0 is no longer being actively maintained.

If I remember correctly, I once read a paper from a uni that modified
gtkwave to handle analog signals with appropriate manipulation
functions (screenshots were in the paper) but they never released their
sourcecode changes back to either me or Manchester.

Adding analog support wouldn't be difficult as the internal data
structures support it, but I've never needed it as my day job is
strictly digital in nature. Maybe I'll add that sometime this summer
as I have a "to do list" of other features to add like a
signalscan-like net select widget, reduction of signal name memory
usage with million net designs, etc.

-Tony

 

[Terry Brown]

Well, the easy way is to select "Display Core Footprint" when you generate
the core. You can also just regenerate and select this to find out about
an existing core.

On Wed, 06 Apr 2005 11:28:20 -0700, rootz wrote:

Guys.
This must seem quite trivial, but how can I tell how many block rams I
am using in a xilinx coregen'ed fifo. Example, how many block rams are
being used in a 256bit by 32 deep fifo.

thanks