More beginner's verilog questions

[Reza Naima]

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

 

[Jason Rosinski]

Reza Naima wrote:

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.

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.

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 :->

 

[Eric Smith]

Ray Andraka wrote:

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.

 

[Reza Naima]

I'm trying to get a tri-state output ([31:0] out). Any idea how to
implement it?

Thnx,
Reza

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.

 

[johnp]

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

 

[Reza Naima]

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

 

[Rob]

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...

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

 

[Ray Andraka]

Reza Naima wrote:

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.

 

[Reza Naima]

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

 

[Reza Naima]

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

 

johnp wrote:

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

I have to agree. No offense, but if you are in an EE graduate level
course, it is shameful that you are asking what a "Digital Design"
course would cover. And everyone has been more than helpful here.
There are SO many resources available on the Internet with respect to
Verilog and Xilinx CPLD/FPGA's. I just started working with the group
in our company that does FPGA systems design and there IS a learning
curve.

I have had to do a lot of reading, a lot of RTL coding and simulation,
and a lot of experimentation. I have asked a couple of questions on
this forum, but have not relied on it for an absolute answer. Don't
get me wrong. It is a great resource, but you are doing yourself a
disservice if you won't try to figure this out on your own. Trust me.
An employer will see this immediately and you won't make it very far.
Just try.

 

"If A do a else do b
If !A do b else do a"

In regards to the above. These statements make "logical" sense. But
it is BAD design practice when writing RTL code. It JUST is. I have
never heard or read any differently. Put your "reset" condition first,
then follow that with your other conditions. I don't pretend to be an
expert, so if anyone has a different opinion, please let me know.

I don't know why the synthesizer has a problem with it, but if it not
immediately intuitive at first glance (which it wasn't), then it very
likely will get more difficult to synthesize. I personally think that
putting the reset condition first like "if (reset condition)..." makes
complete sense. I don't know. I guess I have looked at too much RTL
code here, read too many of our format docs, etc to see it any
differntly. But when you have to write code that will ultimately be
used in an ASIC (not me...others in the company) costing a freaking
ass-ton of money to develop, you tend to keep things consistent.

I would not spend too much time worrying about why your particular
construct wouldn't synthesize. Instead, focus on the de facto
standards that are used. Any Verilog book I have seen, and any Verilog
website with examples that I have seen will help. Writing RTL code is
not a field where you want to be creatively different with regards to
the format.

The best advice I can give is: Do NOT write ANY code until you know
EXACTLY how the circuit will work. This includes FF's and the
combinational logic attached to them. I sometimes draw this out on
paper. Then you write RTL code using your drawing. Then it is just
the process of translating that drawing to code, which should be
relatively trivial.

 

[Jan Decaluwe]

mottoblatto@yahoo.com wrote:

The best advice I can give is: Do NOT write ANY code until you know
EXACTLY how the circuit will work. This includes FF's and the
combinational logic attached to them. I sometimes draw this out on
paper. Then you write RTL code using your drawing. Then it is just
the process of translating that drawing to code, which should be
relatively trivial.

Why not draw the circuit on a computer with a schematic capture
package then? Why the overhead of going through Verilog
and synthesis?

Either that, or your advice is not that good really.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com

 

[Chris F Clark]

You've had people recommend that you "think hardware" and I'm of that
camp. It's one of the reasons for using "templates", each template
corresponds to a specific "piece" of hardware (often called a library
cell in ASIC design, there are similar concepts in FPGA design, but I
don't know if the terminology is changed). In fact, the original
synthesizers were close to template matchers. They simply looked at
the code and matched it to a library of templates and if it found a
match, the synthesizer lay down the piece of hardware corresponding to
that template.

Now synthesizers have grown much smarter, but the basic concept still
holds. This is why, it is important for you as a designer to follow
the templates carefully. If you write verilog that matches the
templates, you can predict exactly what kind of hardware the
synthesizer will create. If your verilog is a little off, the
synthesizer can bend a little to match the templates, but it may do so
by either matching a template that you don't expect or by inserting
extra logic etc.

For example, a "tri-state buffer" in the library I'm failiar with look
like:

assign out[31:0] = enable ? value[31:0] : 32'bz;

If you put this fragment in your verilog and use the library I
mentioned, you will instantiate 32 parallel 1 bit buffers with a
tri-state enable pin, which copy value to output when the enable is
true and leave the value floating if enable is false. You can vary
this template to get 32 distinct enable pins--personally, I would
write that as 32 1 bit assignments, but I'm not a chip designer, just
an architect, so there may be a shorter solution.

However, I would not attempt to put this code into a "clocked always
block". To me that is tempting the synthesizer to match a different
template than I expected (and tri-state buffers are something I know
have specific semantics that I want followed exactly and not have the
synthesizer "winging it"). That's part of the thinking hardware
aspect. I have a specific piece of hardware in mind when I write the
verilog code. I don't mix templates together willy-nilly, as the
synthesizer may figure out what I want and may not. There are some
places where I allow more latitude, because I know the synthesizer can
generate some circuit that will work and the chip designer can modify
the verilog if the synthesizer doesn't generate a circuit which is
"good enough"--state machines are a good example of where this
latitude is usually ok.

This now bring up the last example, you have given:

always @(posedge clk_in or negedge clk_in) begin
....

I don't know what kind of hardware you expect to react exactly to both
rising and falling edges of your clock (and nothing else). Most
synthesizers don't know of such logic either. Therefore, this line is
a recipe for disaster. If you can explain what kind of gates you
expect it to create, there may be another way to write the code.
However, the synthesizers that are complaining that they can't find a
matching template are doing so for good reason.

One final little point on this topic, the code in the templates makes
the verilog behavior match hardware behavior under a set of
assumptions. These assumptions are normally met under the "clocked
digital design regimen". That is, if we only look at the values when
things are stable (in between clocks and when things have had enough
time to settle), the behavior the verilog code models and the behavior
the hardware exhibits will match. However, there are things which
happen in the hardware that don't happen in the verilog model, and
vice versa. Thus, you can in verilog ask if a signal is floating, but
there probably isn't a piece of hardware that can ask that
question. Designers who forget that the hardware and the verilog
"aren't the same" and only behave the same under controlled
conditions, often write verilog code that corresponds only to
imaginary hardware that can't be built. Gross violations won't get
through the synthesizer. More subtle violations will result in pre-
and post- synthesis mismatches or worse a design that simulates but
fails in real hardware under conditions that violate the assumptions
of the simulations.

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)
------------------------------------------------------------------------------

 

It is good advice if you are just starting out designing using an HDL.
If you don't have a picture of the circuit you are describing, then you
may write crappy code. I lied. I do not draw the circuit out. But I
have in the past when I was first starting with simple logic...like
what the guy is trying to do. It is SIMPLE. I can visualize digital
hardware and code from there, but I didn't want to muddy the waters.

Schematic capture would be fine for this example, but defeats the
purpose of trying to learn the HDL. I'm just trying to give helpful
advice to someone who obviously does not know what is going on. "What
would a Digital Design class cover?" Come on. This guy needs to draw
a circuit!!

I am surprised at your response though. Being an "electronic design
consultant", I would think that you would agree with what I said.
Maybe it didn't come across well. I didn't mean "draw your seriously
complex design, and then code it". Do you write code before you know
what your circuit is going to do, or how it will work? If so, I
wouldn't use you as a consultant. Jan.

 

[Ray Andraka]

Reza Naima wrote:

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

RTL = Register Transfer Level. It means the design is specified in

the HDL by describing the registers and the logic that goes between it.
RTL is generally considered to be device independent, but as giving
enough detail to make synthesis fairly easy.

Contrast this with a structural description, which is basically a
netlist containing the FPGA primitives and the wiring connections for
them. Structural implementations are device specific, and leave nothing
for the tools to infer during synthesis; also contrast with behavioral
which describes the black box function of the design but not the details
for the implementation. Behavioral descriptions are generally not
synthesizable.

 

[Andy Peters]

Reza Naima wrote:

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.

Turns out that both Altera's and Xilinx' proprietary synthesis tools,
as well as Synplify and Mentor Precision, use the same constructs to
infer tristate buffers.

And it turns out that all four tools have documentation that clearly
explains how to infer a tristate!

R T F M. Really.

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 the specific case of the reset circuit, you have to realize
something. Perhaps the circuit has an active low reset. In that
case, the condition

if (reset_n)
q <= q + 1;
else
q <= 0;

has a different meaning than

if (~reset_n)
q <= 0;
else
q <= q + 1;

Even though at first glance they appear identical.

You must realize that the async reset _has priority_ over the rest of
the logic, so you must write your code to reflect that. The synthesis
tool helpfully complains if you do it wrong.

-a

 

[Andy Peters]

mottoblatto@yahoo.com wrote:

"If A do a else do b
If !A do b else do a"

In regards to the above. These statements make "logical" sense. But
it is BAD design practice when writing RTL code. It JUST is. I have
never heard or read any differently. Put your "reset" condition first,
then follow that with your other conditions. I don't pretend to be an
expert, so if anyone has a different opinion, please let me know.

I don't know why the synthesizer has a problem with it,

PRIORITY!!!!

The async reset has priority over the synchronous (clocked) logic.
That's why its condition is handled FIRST.

-a

 

[Andy Peters]

Reza Naima wrote:

- 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.

How often the code runs is irrelevant. The question is how long
between changes must you wait for all affected logic to settle.

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.

If you're referring to the code below, I say: Impossible.

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.

It's perfectly legal to use both sides of the clock for different
flip-flops. However, there's no CPLD/FPGA flip-flop that is sensitive
to both edges of the clock.

I thought that if I left that out, any state
change for the signal would initiate the block.

No -- the only things that "initiate" the block are the signals on the
sensitivity list. Which is why a sensitivity list exists.

/* 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

-a

 

[Hal Murray]

I found the RTL schematic viewer - though I sitll am not sure what RTL
stands for.

google works pretty well for that sort of problem. If you can't find
something interesting right away, add acronym to the search list.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.