| Author |
Message |
Chris F Clark
Guest
|
 Posted:
Wed Dec 21, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
See the things in you design which are always @ (posedge xyzzy) begin
foo <= bar, the xyzzy is a clock, even if you don't call it clock.
The foo <= bar is an "edge clocked" flip-flop/register. Things happen
on the posedge of the xyzzy clock. If the clock is "periodic" hooked
up to some kind of oscillator, then it is obvious that it is a
clock. However, even if the clock is not periodic, it is still a clock
and it tells "when" something happens.
Hope this helps,
-Chris
*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------ |
|
| Back to top |
|
 |
johnp
Guest
|
| Posted:
Wed Dec 21, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
I believe that you need to give XST hints to infer logic that maps onto
the architecture. I was at a Xilinx presentation where they used the
RSE letters to denote the order of priority that operations need to
be entered in order to map onto the flip-flop efficietnly:
always @(posedge clk)
if (Reset)
// reset stuff 1st
else if (Set)
// set stuff second
else if (Enable)
// enabled logic last
This is because of the priority of the Reset/Set/Enable functions built
into
the flip-flops.
It could be that the original code fragment confuses the code
generator.
John P |
|
| Back to top |
|
|
Jason Rosinski
Guest
|
| Posted:
Wed Dec 21, 2005 5:15 pm Post subject:
Re: More beginner's verilog questions |
|
|
Hmm, right now I don't see what it's complaining about, since the asynchronous reset is active
high. My suggestion would be to rearrange the blocks a little. Try something like:
always @(posedge counter_increment or posedge reset) begin
if (reset)
index <= 5'b00000;
else
index <= index + 1;
end
Am I missing something obviously wrong with the sensitivity list here? Or is it just a problem
with the synthesiser?
Reza Naima wrote:
| Quote: | Santosh -
I'm not sure if I understand your question, or what an RTL stands for.
Based on the feedback, I rewrote the module so it looks like this (and
is much simpler looking) :
module counterLatch32(counter_increment, in, reset, enable, out);
input in;
input counter_increment;
input reset;
input enable;
output [31:0] out;
reg [4:0] index;
reg [31:0] out;
always @(posedge counter_increment or posedge reset) begin
if (!reset)
index <= index + 1;
else
index <= 5'b00000;
end
always @(posedge enable)
out[index] <= in;
endmodule
I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful? I'm still getting errors. Just
this one so far....
ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.
reza
|
|
|
| Back to top |
|
|
Reza Naima
Guest
|
| Posted:
Wed Dec 21, 2005 5:16 pm Post subject:
Re: More beginner's verilog questions |
|
|
Santosh -
I'm not sure if I understand your question, or what an RTL stands for.
Based on the feedback, I rewrote the module so it looks like this (and
is much simpler looking) :
module counterLatch32(counter_increment, in, reset, enable, out);
input in;
input counter_increment;
input reset;
input enable;
output [31:0] out;
reg [4:0] index;
reg [31:0] out;
always @(posedge counter_increment or posedge reset) begin
if (!reset)
index <= index + 1;
else
index <= 5'b00000;
end
always @(posedge enable)
out[index] <= in;
endmodule
I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful? I'm still getting errors. Just
this one so far....
ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.
reza |
|
| Back to top |
|
|
Ray Andraka
Guest
|
| Posted:
Thu Dec 22, 2005 12:17 am Post subject:
Re: More beginner's verilog questions |
|
|
| Quote: | I still don't see a need for a clock - can someone shed some light into
a case where a clock would be helpful? I'm still getting errors. Just
this one so far....
ERROR:Xst:898 - counterlatch32.v line 12: The reset or set test
condition for <index> is incompatible with the event declaration in the
sensitivity list.
reza
|
Asynchronous logic does not belong in FPGAs. They are not designed for
it and the tools don't support it (especially static timing analysis).
Wires in FPGAs have delays associated with them that are on the same
order of magnitude as the delays through the logic primitives.
While your ripple count structure is a viable clock structure, it does
have some things you need to watch out for: 1), the outputs do not
update all at once, rather the lsb changes, then the next bit and so on,
hence the name ripple count. As the counter gets wider, the maximum
count speed at which you can extract a usable count diminishes (but note
that if you don't need the lower order bits, this can be faster than a
synchronous counter). 2) The input is sensitive to glitches on the
input signal. Mechanical switches will 'bounce', so you'll need to
include logic to filter out the multiple switch closures that happen
every time you actuate the switch.
Timing analysis (studying the time delays in your circuit to make sure
that it will run as fast as you need it to and that it won't break
because of signals getting somewhere either too fast or too late) is
much easier in a synchronous design (one where a common clock is
distributed to all the flip-flops in the design) because each timing
path is punctuated by the flip-flops...you only need to evaluate the
propagation delay time from flip-flop to flip-flop. In an async system,
you need to take into account the propagation delays on all paths from
the input to the output to make sure you don't have race conditions that
would upset the proper operation of your circuit. Also, synchronous
design eliminates the dynamic hazards you need to deal with in an async
design.
Even asynchronous resets are bad for FPGA design. First, the tools
don't trace the delay paths for the asynchronous reset through the
flip-flop, so you could wind up with timing hazards and not be aware of
it. Second, there are start up hazards which have been discussed ad
nauseum here in the past. If you really need an async behavior, for
whatever reason, just connect the external async reset to the PROGRAM
pin on the FPGA. |
|
| Back to top |
|
|
Reza Naima
Guest
|
| Posted:
Thu Dec 22, 2005 1:15 am Post subject:
Re: More beginner's verilog questions |
|
|
I'm trying to get a tri-state output ([31:0] out). Any idea how to
implement it?
Thnx,
Reza
| Quote: | I guess that depends on whether you're trying to tri-state an output pad from the FGPA itself or
an internal node. Are you trying to create a tri-state bus WITHIN the FPGA? I've never tried to
synthesize something like that but I guess you'd have to use the 'z' constant. Never tried it.
If you're tristating an output I'd expect a tri-state enable connection to the pad itself. That
will be much more tool specific.
|
|
|
| Back to top |
|
|
johnp
Guest
|
| Posted:
Thu Dec 22, 2005 1:15 am Post subject:
Re: More beginner's verilog questions |
|
|
Reza -
I suggest you do some studying on your own rather than asking this
group to design your circuit.
On your tri-state question, try Google "verilog tristate", then do some
reading.
John Providenza |
|
| Back to top |
|
|
Eric Smith
Guest
|
| Posted:
Thu Dec 22, 2005 1:15 am Post subject:
Re: More beginner's verilog questions |
|
|
Ray Andraka wrote:
| Quote: | Asynchronous logic does not belong in FPGAs. They are not designed
for it and the tools don't support it (especially static timing
analysis).
|
I recently needed a data path with a 56-bit adder/subtractor with binary
and BCD modes. I thought I might have to pipeline it, but was
pleasantly surprised that the Xilinx tools did a very good job with it
as purely combinatorial logic.
The inputs come from a mux from one of five registers or a few other
sources, and the outputs can be loaded into any of four registers. As
an additional complication, the arithmetic operation may be performed on
any subrange of four-bit digits of the 56-bit word, which means that
there is a 14:1 mux for carry out, and 2:1 muxes in the carry of each
digit.
I designed a four-bit slice using three ripple-carry adders: one to
generate the one's or nine's complement of the subtrahend, one for the
binary addition, and one for the for the BCD correction of the result.
For each digit, I use two of those slices, one with the carry-in tied
high, and one with it tied low. The carry outs of those act as the
generate and propogate outputs for a carry lookahead scheme. And the
data outputs feed a multiplexer selected by the carry-in computed by the
lookahead carry logic, so they act as carry-select adders.
When I set the mapper to use timing-directed mapping, and the PAR to
high effort, ISE 8.1i was able to reduce it to ten levels of logic
(including the input muxing), and static timing analysis says it will
run with under 20 ns clock cycle in an XC3S1000-4 (the slower speed
grade).
I was not expecting the tools to be able to optimize it this well,
especially as synthesis translated the carry-lookahead code, which I'd
carefully written describing very flat logic, into a thirteen-deep tree.
But apparently the mapper and PAR were smart enough to flatten it again.
The static timing analysis had to analyze an immense number of paths.
But I don't have any feedback loops in the logic, so I guess analysis of
it isn't particularly difficult, just a large combinatorial problem.
A pipelined design would probably achieve better throughput, but worse
latency, and for my purposes latency was important. I'm not very
experienced with complex data path and arithmetic design, so perhaps
there are more efficient ways to implement a binary/BCD add/subtract
slice, but even so I don't expect that it's possible to reduce the
number of levels of logic of the purely combinatorial approach much. |
|
| Back to top |
|
|
Jason Rosinski
Guest
|
| Posted:
Thu Dec 22, 2005 1:16 am Post subject:
Re: More beginner's verilog questions |
|
|
Reza Naima wrote:
| Quote: | Before I start replying to people, I was just wondering, how is it
possible such that I can assign a high-impedence state to an output
using the code I wrote? Can I do it using the same number of inputs,
or do I have to add another input and implement it in this way..
always @(posedge clear)
out[index] <= z
or something like that?
|
I guess that depends on whether you're trying to tri-state an output pad from the FGPA itself or
an internal node. Are you trying to create a tri-state bus WITHIN the FPGA? I've never tried to
synthesize something like that but I guess you'd have to use the 'z' constant. Never tried it.
If you're tristating an output I'd expect a tri-state enable connection to the pad itself. That
will be much more tool specific.
| Quote: | Yep, this did the trick, and managed to piss me off at the same time.
I don't see how this code is logically any different from the code that
I posted! Several people posted about hints and priorities for
coding, but in my reading, I never came across references to these
things. Does anyone have any good pointers or references?
|
Well, synthesis tools usually infer priority to if-else constructs. Now, you can argue that with
a single condition to the 'if-else' that neither block has higher priority. But with nested trees
of if-else's there is a definite priority.
So the synthesizer has to map the code to cells existing in the FPGA. With an asynchronous reset
to a FF it's really a level sensitive input. Anytime that the reset is asserted the output should
be driven to the reset state. Might not seem like a level sensitive input, but it is. If 'posedge
clk' occurs it should not be able to set the outputs, hence the highest priority portion of the 'if'
structure is the comparision against the asynchronous reset.
But the way that you had it written it had the non-reset case as the highest priority in the
if-else statement. I've argued in the past with people that there is NO priority for a simple two
segment if-else since there is no nesting of branches, but it's kinda semantic.
| Quote: | This behaviour makes no logical sense again, just as this notion of
having to fllow templates and priorities. Is there any benefit for
such a strict structure? If a reset is higher in priority, why doesn't
the compiler/synthesizer just take care of it. Why not just give me a
warning rather than a hard error.
|
One of the issues is that you're not creating new base cells. Just mapping to existing ones. As
for the 'template' type aspect, it's a matter of strict logical correctness. If it can't map the
behaviour that you've specified to an existing cell, what else can it do?
Also, don't forget that someone had to code the synthesizer :-> |
|
| Back to top |
|
|
Reza Naima
Guest
|
| Posted:
Thu Dec 22, 2005 1:16 am Post subject:
Re: More beginner's verilog questions |
|
|
Before I start replying to people, I was just wondering, how is it
possible such that I can assign a high-impedence state to an output
using the code I wrote? Can I do it using the same number of inputs,
or do I have to add another input and implement it in this way..
always @(posedge clear)
out[index] <= z
or something like that?
Jason -
Yep, this did the trick, and managed to piss me off at the same time.
I don't see how this code is logically any different from the code that
I posted! Several people posted about hints and priorities for
coding, but in my reading, I never came across references to these
things. Does anyone have any good pointers or references?
Ray -
Is it acceptible to use asynchronous code in fpga's/cpld's if you are
going to be working at very low speeds? I'm not looking for a high
performance design, rather, a super-low-power deisgn that'll save me
pins on a microcontroller. I just want the ability to program one of
32 outputs using a minimal set of microcontroller pins.
With regards to switch bouncing, as it'll be switched from a
microcontroller, I dont have to deal with debounce, right?
Finally, I'm not sure what the reset/startup up hazards are -- I'll do
some googling after I post this. The reset I use is just to reset the
counter to zero. Will this be problematic?
Andy -
Thanks for the hint about the falling edge of the enable pin. Can you
provide me with some some pointers as to why this behaviour is the way
it is - or a starting point when I'm going through the manual.
This behaviour makes no logical sense again, just as this notion of
having to fllow templates and priorities. Is there any benefit for
such a strict structure? If a reset is higher in priority, why doesn't
the compiler/synthesizer just take care of it. Why not just give me a
warning rather than a hard error.
I also checked my course schedule, and there are not classes called
Digital Electronic Design or anything like that. What material would
such a course cover? Also, the project can't wait. If it can't be
done in a CPLD, we'll have to do it using either a larger
microcontroller or discrete multiplexers/counters. We're building an
implantable wireless neural recording device to record and transmit
data from a 32 channel probe, and the key factors are size and power
consuption (in that order). The entire device should be no bigger than
two quarters stacked on top of each other - which is why I wanted to go
with a CPLD rather than a large microcontroller or several discrete
components.
Thanks everyone for your help so far!
Reza |
|
| Back to top |
|
|
Reza Naima
Guest
|
| Posted:
Thu Dec 22, 2005 8:52 am Post subject:
Re: More beginner's verilog questions |
|
|
John,
I'm just trying to use the usenet as a resource to learn. In reading
other sources, it seems that I could output a 'z' in order to achieve a
tri-state -- however, as I've found out, there is a lot of strange
behaviour in actually going from verilog syntax to application and
implementation. I wanted to see if there were any gotcha's in this
approach. I also wanted to know if it was possible for a physical
input to read 'z' if I configure the microcontroller's pin as an input
(putting it in tri-state), or if I would have to add another pin (say,
enable_Z) to specify when I want the output to be equal to 'z'. I'm
also not sure about the implementation differences - say, between
xilinx and altera, and if one supports a certain mode of opperation
that the other does not.
I'll do some more googling on verilog and tristate, however, I also
find that there are people willing to help answer questions, which I
greatly appreciate. I'm not asking anyone to design my circuit -
though people have helped with some of the debugging issues which has
been invaluable.
Another aspect of my questions is trying to understand the strange
behaviour. I still don't see why the synthesizer has a problem
equating these two constructs :
If A do a else do b
If !A do b else do a
they seem identical to me, and I'll have to do some more research and
re-read some of the replies to this thread to try to figure it out.
In any case, thanks,
Reza |
|
| Back to top |
|
|
Rob
Guest
|
| Posted:
Thu Dec 22, 2005 9:15 am Post subject:
Re: More beginner's verilog questions |
|
|
Both Altera and Xilinx give the ability to look at the RTL schematic which
will show you what the synthesizer did with your code. I don't know if the
free versions give you this ability????
Your question about whether or not your microprocessor can read a 'z'
clearly tells us that you're not an engineer working in industry.
"Reza Naima" <google@reza.net> wrote in message
news:1135219926.957661.32390@g47g2000cwa.googlegroups.com...
| Quote: | John,
I'm just trying to use the usenet as a resource to learn. In reading
other sources, it seems that I could output a 'z' in order to achieve a
tri-state -- however, as I've found out, there is a lot of strange
behaviour in actually going from verilog syntax to application and
implementation. I wanted to see if there were any gotcha's in this
approach. I also wanted to know if it was possible for a physical
input to read 'z' if I configure the microcontroller's pin as an input
(putting it in tri-state), or if I would have to add another pin (say,
enable_Z) to specify when I want the output to be equal to 'z'. I'm
also not sure about the implementation differences - say, between
xilinx and altera, and if one supports a certain mode of opperation
that the other does not.
I'll do some more googling on verilog and tristate, however, I also
find that there are people willing to help answer questions, which I
greatly appreciate. I'm not asking anyone to design my circuit -
though people have helped with some of the debugging issues which has
been invaluable.
Another aspect of my questions is trying to understand the strange
behaviour. I still don't see why the synthesizer has a problem
equating these two constructs :
If A do a else do b
If !A do b else do a
they seem identical to me, and I'll have to do some more research and
re-read some of the replies to this thread to try to figure it out.
In any case, thanks,
Reza
|
|
|
| Back to top |
|
|
Reza Naima
Guest
|
| Posted:
Thu Dec 22, 2005 9:15 am Post subject:
Re: More beginner's verilog questions |
|
|
Rob,
I never asked if a microprocessor could read a 'z', I asked if a CPLD
could determine if an input was floating or not - though I doubt it
could. And as I've stated, I'm a graduate student, so I'm obviously
not working in industry. I take it you like to skim.
I found the RTL schematic viewer - though I sitll am not sure what RTL
stands for.
Reza |
|
| Back to top |
|
|
Ray Andraka
Guest
|
| Posted:
Thu Dec 22, 2005 9:15 am Post subject:
Re: More beginner's verilog questions |
|
|
Reza Naima wrote:
| Quote: | Before I start replying to people, I was just wondering, how is it
possible such that I can assign a high-impedence state to an output
using the code I wrote? Can I do it using the same number of inputs,
or do I have to add another input and implement it in this way..
always @(posedge clear)
out[index] <= z
or something like that?
Jason -
Yep, this did the trick, and managed to piss me off at the same time.
I don't see how this code is logically any different from the code that
I posted! Several people posted about hints and priorities for
coding, but in my reading, I never came across references to these
things. Does anyone have any good pointers or references?
Ray -
Is it acceptible to use asynchronous code in fpga's/cpld's if you are
going to be working at very low speeds? I'm not looking for a high
performance design, rather, a super-low-power deisgn that'll save me
pins on a microcontroller. I just want the ability to program one of
32 outputs using a minimal set of microcontroller pins.
With regards to switch bouncing, as it'll be switched from a
microcontroller, I dont have to deal with debounce, right?
Finally, I'm not sure what the reset/startup up hazards are -- I'll do
some googling after I post this. The reset I use is just to reset the
counter to zero. Will this be problematic?
|
Generally, you should avoid async logic. By using it, you are making
your job a lot harder, and substantially increasing the risk of making a
grave design error that may not show up until the device is fielded.
Yes, asynchronous designs are possible in FPGAs and CPLDs, but it takes
a considerable amount of additional design evaluation and verification
effort to make sure you did it right. Often times, it also involves
hand routing to maintain control of the path delays, and it certainly
includes timing analysis by hand because the static timing tools are not
suited to async circuit evaluation. I would certainly strongly
discourage someone who is having trouble understanding the advantages of
a synchronous design taking an asynchronous approach to the design.
The issue is not the speed of the design, it is the numerous hazards
present in an async design that are eliminated by synchronous design
techniques. The fact that the wires connecting the elements have delay
in an FPGA and that delay varies significantly for each routing solution
makes the analysis of an async design in an FPGA extremely tedious,
error prone, and difficult. As soon as you have to make a modification
to the design, you basically have to start over on the analysis. If you
don't have time to learn how to do a basic synchronous design, you don't
have the time to do the async design properly either.
The reset/start up hazards in a synchronous design with async reset is
that unless the release of reset is done synchronously, you can't
guarantee that all affected logic is going to see the release of reset
on the same clock cycle, so it can wind up leaving the reset state in an
unknown condition. Your reset to zero is OK as long as you can
guarantee all of the counter flip-flops will not be clocked until the
set-up times to all the flip-flops have been satisfied.
Finally, an FPGA or CPLD is generally NOT suitable for an implantable
device. Even the static current greatly exceeds the current draw needed
for a reasonable battery life, regardless of what the dynamic currents
are in your design. The FPGA or CPLD is fine for a prototype, but not
for the actual implant. Finally, if speed is not a consideration and
power is, there is no reason you can't make the design synchronous and
slow the clock down to the minimum clock you need. A 32KHz digital
watch crystal will provide a dynamic power that is barely detectable
over the static ICC in most FPGAs and CPLDs. Also, the power savings
for an async design in and FPGA is largely a mirage. By using
synchronous techniques you take advantage of purpose built structures in
the FPGA such as the optimized clock tree and fast logic for carry
chains, and other arithmetic. Async logic often has to use LUT
resources and general purpose routing instead, and because the routing
is actually a network of powered switches, the power dissipation is
quite a bit higher than you might expect. Also, there have been papers
showing that a heavily pipelined (ie very little logic between
flip-flops) design shows significant power reductions (on the order of
20-30%) over the same design with fewer pipeline stages. The difference
is the flip-flops stop the propagation of glitches, which in turn
dissipates a significant amount of power not only in the logic but also
in the active routing resources.
I strongly encourage you to take a bit of time to learn synchronous
design. I'd pick up a basic logic text such as Morris Mano and start
reading up on synchronous logic. |
|
| Back to top |
|
|
Reza Naima
Guest
|
| Posted:
Thu Dec 22, 2005 3:17 pm Post subject:
Re: More beginner's verilog questions |
|
|
Ray,
Thanks for the excellent advice and help. A few comments/responses.
- The implant is actually inductivly powered through the skin and there
is no battery. For the xlinix chips I was looking at, quiesent power
consuption was under 30uA which is perfectly fine. We're looking at
having about 50-100mA @ 3.3v available to use for all components (amp,
a2d, uC, cpld, telemetry system).
- The async verilog code will only be run once every few days, and will
be controlled from a microcontroller that I can tweak to guarantee
sufficient time between each state change. I do have a clock available
that I could feed into it to make it a synchronous design - but I'll go
for the async first to see if I can get it to work.
- I'll look into finding a copy of Morris Mano's book.
Thanks,
Reza
p.s. I've added some extra code (see below) that is synthesized just
fine on one of the xilinx CPLDs, but gives errors if I configure it for
another CPLD types. It says it can't find a matching template for the
other cpld architectures. I also found that I had to do the posedge
and negedge explicitly. I thought that if I left that out, any state
change for the signal would initiate the block.
/* cs toggler - cs goes high for one clock cycle every 17 clk_in
cycles */
always @(posedge clk_in or negedge clk_in) begin
sck = !sck;
spi_counter <= spi_counter + 1;
if (spi_counter == 16)
cs <= 1;
if (spi_counter == 17) begin
cs <= 0;
spi_counter <= 0;
end
end |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in