T
Tristan Gingold
Guest
sharp@cadence.com wrote:
Tristan.
structure is mapped in memory...
Tristan.
N
Neo
Guest
I dont know which one is your actual code. but the first one dosent
include the clock in any block and in the second you dont get twin edge
clock triggered flops in fpga.
include the clock in any block and in the second you dont get twin edge
clock triggered flops in fpga.
Guest
The defparams were my first guess also. And in this case,
there is no point in using defparams, since it is easy to do
the much cleaner overrides on the instantiation. However,
there is a slight error in Jim's example: he used the name
of the instance instead of the name of the parameter in the
override. It should be
reg_fd #(.width(1), .ainit_val(0),...)
simple_reg (.clk(c)...
there is no point in using defparams, since it is easy to do
the much cleaner overrides on the instantiation. However,
there is a slight error in Jim's example: he used the name
of the instance instead of the name of the parameter in the
override. It should be
reg_fd #(.width(1), .ainit_val(0),...)
simple_reg (.clk(c)...
J
J o h n _ E a t o n (at)
Guest
john.deepu@gmail.com wrote:
create logic that works but cannot be simulated unless you have a way
to initialize registers to a known value. (Anything but X).
But as you noticed it can be costly to put a reset on every flop in the
design. Not only is there an area cost but you have to route that reset
around the entire chip and meet setup/hold timing on every flop.
I like the idea of multicycle resets where you are required to hold a reset
for X number of cycles. Then as long as you can reset everything by cycle
X then everything will work.
John Eaton
One problem can occur with back annotated gate sims. It is possible to
create logic that works but cannot be simulated unless you have a way
to initialize registers to a known value. (Anything but X).
But as you noticed it can be costly to put a reset on every flop in the
design. Not only is there an area cost but you have to route that reset
around the entire chip and meet setup/hold timing on every flop.
I like the idea of multicycle resets where you are required to hold a reset
for X number of cycles. Then as long as you can reset everything by cycle
X then everything will work.
John Eaton
K
KCL
Guest
For simulation probleme you could put a value to your signal when you
declare it
like:
signal temp : std_logic :='0';
like that it will have an initial value different from X at start but will
not be synthetized
Alexis
"J o h n _ E a t o n (at) hp . com (no spaces)" <"J o h n _ E a t o n (at)
hp . com (no spaces)"> a écrit dans le message de news:
42263428$1@usenet01.boi.hp.com...
declare it
like:
signal temp : std_logic :='0';
like that it will have an initial value different from X at start but will
not be synthetized
Alexis
"J o h n _ E a t o n (at) hp . com (no spaces)" <"J o h n _ E a t o n (at)
hp . com (no spaces)"> a écrit dans le message de news:
42263428$1@usenet01.boi.hp.com...
N
nonoe
Guest
"KCL" <kclo4_NO_SPAM_@free.fr> wrote in message
news:422642ed$0$25040$8fcfb975@news.wanadoo.fr...
may reject the equivalent:
reg q;
initial q = 1'b0; // for simulation-only!
.....
(or for a more modern Verilog-2001 tool)
reg q = 1'b0;
news:422642ed$0$25040$8fcfb975@news.wanadoo.fr...
Perhaps that works easily with VHDL, but many Verilog synthesis tools
may reject the equivalent:
reg q;
initial q = 1'b0; // for simulation-only!
.....
(or for a more modern Verilog-2001 tool)
reg q = 1'b0;
T
Thomas Stanka
Guest
Hi,
john.deepu@gmail.com wrote:
I was told that this will be not acceptable for the ASIC vendor. Maybe you
should check the needs of your vendor.
bye Thomas
--
Emailantworten bitte an thomas[at]obige_domain.
Usenet_10 ist für Viren und Spam reserviert
john.deepu@gmail.com wrote:
If you insert these FF in a scan chain, you could not reset them.
I was told that this will be not acceptable for the ASIC vendor. Maybe you
should check the needs of your vendor.
bye Thomas
--
Emailantworten bitte an thomas[at]obige_domain.
Usenet_10 ist für Viren und Spam reserviert
C
chainastole
Guest
Without thorough inspection of the code, try to make all the
assignments non-blocking.
assignments non-blocking.
R
Ray Andraka
Guest
john.deepu@gmail.com wrote:
invisible by a) making sure you break all internal loops by forcing a
reset on one element in the loop and holding that reset for enough
clocks to make the known data propagate all the way around the loop, and
b) putting reset on all the output registers that is applied immediately
and then held until good data propagates to the output register. The
output register reset can easily be accomplished by using a sync RS-FF
that is set by the reset input signal and then cleared by either a
delayed version of the input reset signal or using a counter that is
preset by the input reset signal and whose terminal count clears that
FF. Same is true for the loop resets.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
accept anything less than 100% reset. You can make the reset totally
invisible by a) making sure you break all internal loops by forcing a
reset on one element in the loop and holding that reset for enough
clocks to make the known data propagate all the way around the loop, and
b) putting reset on all the output registers that is applied immediately
and then held until good data propagates to the output register. The
output register reset can easily be accomplished by using a sync RS-FF
that is set by the reset input signal and then cleared by either a
delayed version of the input reset signal or using a counter that is
preset by the input reset signal and whose terminal count clears that
FF. Same is true for the loop resets.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
M
MysticSage
Guest
Since you are new to Verilog, these kind of issues will be coming but
keep trying...
One thing to pay attention is Simulation-Synthesis mismatch. And it is
because of difference in Simulation tool behavior (which is software
approach) and Synthesis Tool behavior (which is hardware approach).
Both tool may interprete these construct differenently and hence, the
problem. On top of that there may be bunch of other problems.
Good news is that by changing coding style, these issues can be
avoided. Hence in industry, there are certain coding guidelines. Try
following guidelines -
1. Use only one kind of reset. In your code, you are using 2 kind of
resets, one is reset and other is start_pulse_enable.
2. In sequential blocks ( i.e. always @(posedge clock .......)),
always use non-blocking assignments.
3. In combinatorial blocks, use blocking assignment.
4. Never mix-match blocking and non-blocking.
5. Always have complete branches in if-elseif-else. I think you have
it, but review your code again to make sure.
After these changes, your simulation and synthesis will match. And
you'll be able to debug problem more easily.
keep trying...
One thing to pay attention is Simulation-Synthesis mismatch. And it is
because of difference in Simulation tool behavior (which is software
approach) and Synthesis Tool behavior (which is hardware approach).
Both tool may interprete these construct differenently and hence, the
problem. On top of that there may be bunch of other problems.
Good news is that by changing coding style, these issues can be
avoided. Hence in industry, there are certain coding guidelines. Try
following guidelines -
1. Use only one kind of reset. In your code, you are using 2 kind of
resets, one is reset and other is start_pulse_enable.
2. In sequential blocks ( i.e. always @(posedge clock .......)),
always use non-blocking assignments.
3. In combinatorial blocks, use blocking assignment.
4. Never mix-match blocking and non-blocking.
5. Always have complete branches in if-elseif-else. I think you have
it, but review your code again to make sure.
After these changes, your simulation and synthesis will match. And
you'll be able to debug problem more easily.
Guest
The Verilog-2001 specification was unclear about genvars and
how they behaved. Stu's guidebook is clearly not quite accurate
either, since a genvar is not really a variable. It is a constant
within
any given instance of a generate-for block, and yet it seems to take
on different values in different instances. And there is the concept
of it stepping through values while creating those instances, like
a variable, but that only happens at some undefined time during
elaboration.
The Verilog-2005 LRM will fix some problems with generates, and
also clarify some things about them. One of them is what it means
when you reference a genvar inside a generate for. Each instance
of the named block inside a generate-for implicitly declares a
localparam with the same name as the genvar and a constant value
corresponding to the genvar value for that iteration. The references
to the genvar inside the named block inside the generate-for are
actually references to the implicit localparam. Each instance of the
loop body has its own instance of the localparam, so they are all
constant but have different values.
This is not just a formal way of explaining how genvars work. The
references really are treated as references to a localparam. If you
use VPI to access the genvar identifier used in an expression, it
should give you back a localparam. And more importantly for your
question, you can do anything with it that you could do with a
localparam. That includes taking a bit-select or part-select.
how they behaved. Stu's guidebook is clearly not quite accurate
either, since a genvar is not really a variable. It is a constant
within
any given instance of a generate-for block, and yet it seems to take
on different values in different instances. And there is the concept
of it stepping through values while creating those instances, like
a variable, but that only happens at some undefined time during
elaboration.
The Verilog-2005 LRM will fix some problems with generates, and
also clarify some things about them. One of them is what it means
when you reference a genvar inside a generate for. Each instance
of the named block inside a generate-for implicitly declares a
localparam with the same name as the genvar and a constant value
corresponding to the genvar value for that iteration. The references
to the genvar inside the named block inside the generate-for are
actually references to the implicit localparam. Each instance of the
loop body has its own instance of the localparam, so they are all
constant but have different values.
This is not just a formal way of explaining how genvars work. The
references really are treated as references to a localparam. If you
use VPI to access the genvar identifier used in an expression, it
should give you back a localparam. And more importantly for your
question, you can do anything with it that you could do with a
localparam. That includes taking a bit-select or part-select.
N
Neo
Guest
I feel you should write the condition as suppose I want c after a
followed by b: then property cafterab is always {a;b} |=> {c}. ie the
satisfying conditions should all be on the LHS and the condition being
checked should be on the RHS.
post this in verification guild site to get more feedback.
followed by b: then property cafterab is always {a;b} |=> {c}. ie the
satisfying conditions should all be on the LHS and the condition being
checked should be on the RHS.
post this in verification guild site to get more feedback.
I
info_
Guest
moti@terasync.net wrote:
have the code declaring the vectors).
So with 8 bits vectors, ff + 1 = 100 and ff + 1'b1 = 00
If I'm correct, the RHS is extended to at least 32 bits (probably unsigned, I don't
have the code declaring the vectors).
So with 8 bits vectors, ff + 1 = 100 and ff + 1'b1 = 00
I
info_
Guest
eva wrote:
You have n-1 extra clock domains and the counter's bits toggle at different times !
It's viable only if you use this as a divider and use only the last bit, but even
then, this last bit is very much skewed from the clock signal. And you need to make
sure your synthesizer & tech mapper won't try to use (waste) global signals for these
intermediate clocks.
It's not really "asynchronous" (no clock), but it's almost as bad
Very high speed clock division is probably better done with a Johnson "counter" which
is fully synchronous and can run near the max toggle rate.
Bert
Horrible practice
You have n-1 extra clock domains and the counter's bits toggle at different times !
It's viable only if you use this as a divider and use only the last bit, but even
then, this last bit is very much skewed from the clock signal. And you need to make
sure your synthesizer & tech mapper won't try to use (waste) global signals for these
intermediate clocks.
It's not really "asynchronous" (no clock), but it's almost as bad
Very high speed clock division is probably better done with a Johnson "counter" which
is fully synchronous and can run near the max toggle rate.
Bert
G
glen herrmannsfeldt
Guest
moti@terasync.net wrote:
same either way. Many compilers will give a warning anyway,
because the sum will be one bit wider, even though verilog says
it shouldn't be (when the destination width is known).
Use whichever looks best.
-- glen
You might get warnings from synthesis, but it should work the
same either way. Many compilers will give a warning anyway,
because the sum will be one bit wider, even though verilog says
it shouldn't be (when the destination width is known).
Use whichever looks best.
-- glen
G
glen herrmannsfeldt
Guest
paulw@mmail.ath.cx wrote:
(
block.
a=b+c;
d=a+b;
-- glen
(
You should also not change any variables used later in the same
block.
a=b+c;
d=a+b;
-- glen
J
John_H
Guest
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:d29vdv$ttq$1@gnus01.u.washington.edu...
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.
Simulation test benches are typically run sequentially which lend themselves
to blocking operators and time delays between some of those blocking
operators. If there's an always @posedge style construct in the testbench,
that should still use non-blocking operators if no time delays are
introduced. Blocking operators would fit right into those blocks if the
intent is to introduce a time-separated series of conditions after each
edge.
They both have their place.
news:d29vdv$ttq$1@gnus01.u.washington.edu...
< snip >
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.
Simulation test benches are typically run sequentially which lend themselves
to blocking operators and time delays between some of those blocking
operators. If there's an always @posedge style construct in the testbench,
that should still use non-blocking operators if no time delays are
introduced. Blocking operators would fit right into those blocks if the
intent is to introduce a time-separated series of conditions after each
edge.
They both have their place.
I
info_
Guest
Hi Paul,
LOTs of more or less wrong things has been said and published about NBAs & BAs.
People coming from VHDL will likely not be as confused.
In just a few words :
In RTL code :
NBAs are updated "later" like signals are in VHDL, and they share the same
assignement symbol "<=". They refer to the Q ouputs (or "old value) of your FFs in
clocked always.
NBAs are perfect to describe the behavior of nets, and avoid racing conditions.
BAs should be usually avoided (in clocked RTL) since they are updated "immediately".
In VHDL, they apply only to another type called "variable", with ":=".
VHDL variables are not visible outside the process (always block) in which they are
declared, so this avoid the Verilog "problems" related with BAs.
Use BAs in a clocked always when you need intermediate values to be used below in the
same always block, or to get to the "D" input of your flipflops.
In simulation code, VHDL variables and BAs are welcome since they simulate faster
(well usually).
Sorry it's quite terse, but I hope you'll get the idea.
Bert Cuzeau
paulw@mmail.ath.cx wrote:
LOTs of more or less wrong things has been said and published about NBAs & BAs.
People coming from VHDL will likely not be as confused.
In just a few words :
In RTL code :
NBAs are updated "later" like signals are in VHDL, and they share the same
assignement symbol "<=". They refer to the Q ouputs (or "old value) of your FFs in
clocked always.
NBAs are perfect to describe the behavior of nets, and avoid racing conditions.
BAs should be usually avoided (in clocked RTL) since they are updated "immediately".
In VHDL, they apply only to another type called "variable", with ":=".
VHDL variables are not visible outside the process (always block) in which they are
declared, so this avoid the Verilog "problems" related with BAs.
Use BAs in a clocked always when you need intermediate values to be used below in the
same always block, or to get to the "D" input of your flipflops.
In simulation code, VHDL variables and BAs are welcome since they simulate faster
(well usually).
Sorry it's quite terse, but I hope you'll get the idea.
Bert Cuzeau
paulw@mmail.ath.cx wrote:
G
glen herrmannsfeldt
Guest
sharp@cadence.com wrote:
That is, it doesn't synthesize a 32 bit adder even though the
logic asks for one. I can't guarantee that, though.
The case where you definitely need the bit length is in
concatenations.
assign x={ y, 4'b1010, z};
-- glen
For all the tools I have used, the extra logic is removed.
That is, it doesn't synthesize a 32 bit adder even though the
logic asks for one. I can't guarantee that, though.
The case where you definitely need the bit length is in
concatenations.
assign x={ y, 4'b1010, z};
-- glen
J
John_H
Guest
People often *multiply* clocks by 2 using a delay element and an XOR
forceing every edge of an incoming clock to produce a pulse with a width
based on the delay element. Clock dividion needs storage elements whether
dedicated registers/latches or storage elements built from primitives.
"eva" <vitaminc.eva@gmail.com> wrote in message
news:e2e21544.0503291327.1d0033d0@posting.google.com...
> or in general, not using any FF's. Thanks in advance for any reponse!~
forceing every edge of an incoming clock to produce a pulse with a width
based on the delay element. Clock dividion needs storage elements whether
dedicated registers/latches or storage elements built from primitives.
"eva" <vitaminc.eva@gmail.com> wrote in message
news:e2e21544.0503291327.1d0033d0@posting.google.com...
> or in general, not using any FF's. Thanks in advance for any reponse!~