I hate VHDL!!!

[Jim Granville]

Jerker Hammarberg (DST) wrote:

If you consider .D registered FSMs, then if you have enumerated 00000
as a legal state, that naturally maps what you call recovery logic.
If the tools choose one-hot, and take 00000 as illegal/not possible,
(since it is not a one-hot state) then you loose the natural recovery
path. ie the state encoding itself CAN affect the recovery, as if you
avoid the .D recovery path of all low, your FSM will not perform
the same as one that includes all lows as a specified state.

But that only solves the problem for one specific illegal state... or do
I misunderstand something? Say I have a three-state machine, where XST
by default would encode the states "100", "010", and "001". So there are
now five illegal states. If I follow your suggestion, I could encode the
states like "00", "10", and "01". But there is still one illegal state,
namely "11". I agree this is a lot better and it significantly reduces
the risk of falling into the illegal state, but the risk is still there.
And if the machine somehow falls into this illegal state, I want there
to be some recovery logic to take the machine out of it.

Simply put - no matter what encoding I use, there will always be illegal
states (except when the number of states is an exact power of two, so
that I can assign each state vector configuration to a legal state). And
if there are illegal states, the machine can fall into them. And if the
machine can fall into an illegal state, I want it to get out of there
automatically.

With .D registers, and you can consider FSMs as low level coded as:
Q0.D = SeriesOfTerms0;
Q1.D = SeriesOfTerms1;

Each valid state will have a number of hold-until-next-move-true terms,
but states not covered will have NO .D terms, and so their NEXT state is
Q0.D = 0;
Q1.D = 0;
or to the 00 state.

If you code
IF State=11 THEN immediate_next = 00, then no more logic is generated,
as that is implicit.

So it will get out of there automatically. With one-hot, the actual
problem is that where it GOES NEXT is also not on the state map, whereas
with other schemes, esp if you implicitly include 0000, then there is a
recovery path.

Try Gray or Johnson, and make sure the 00000 is an
enumerated/specified state, and see what happens ?

I have tried binary encoding, and indeed wouldn't hang anymore. But
considering what I wrote above, I don't feel confident that it really
solved the problem - I believe I just reduced the probability for it to
happen. But I would happily be proved wrong!

See above.

 

[Philip Freidin]

Hi Jerker,

From reading your various postings, I believe the summary is:

You have a state machine.
It gets into illegal states.
It does it about 1 out of 10 times on startup.
You do not have an async reset to the FSM.
Your async inputs to the state machine go through a single flipflop.
You are investigating ways of detecting illegal states and want to get back to a valid state.
You specify initial values (in VHDL).
Your static timing analysis indicates no problems.
Your clock frequency is 20MHz.

On Wed, 7 Jul 2004 19:51:32 +0200, "Jerker Hammarberg \(DST\)" <jerkerNO@SPAMdst.se> wrote:

Hi all! I'd like to once again bring up the subject of state machines
running into illegal states (illegal in the sense that the state vector does
not correspond to any of the states defined in the VHDL code), ...

1. Most discussions cover how to recover from illegal states, but few cover
how it actually happens. ...

2. How can I force Xilinx XST (6.2 SP3) to produce a safe FSM that recovers
from an illegal state? ...

/Jerker

In summary from other postings:

This might be metastables.
This might be a timing problem.
There is an asyc reset, which occurs when your chip goes active.
(FPGAs and CPLDs do this differently, but the effect is similar)
There are various noise sources that could cause this:
kai: "Internal noise coupling in the chip (crosstalk), power drops, alpha
particles, not properly double-sync'ing an async signal before using
it in two different places ... the list goes on!
Phil Hays wrote: "You do have an asynchronous reset, you just didn't know that
you did. When a Xilinx FPGA finishes the program download, it has all
initial values held until an internal signal is released. This release
is asynchronous to your clock. To avoid problems with this add a counter
that is reset to all zeros. Until that counter counts to 15, keep the
state machine in the initial state."
Rickman wrote: "Figure out what is wrong and deal with the cause of the problem."
You wrote: "I doubt that it's about static timing in my case since my clock is 20
MHz, and XST's post-layout static timing analysis doesn't complain.
Metastability could be an issue, but it's strange that it happens so
often. On one particular design, it happens about once every ten times i
startup the system. All inputs are synchronized with one FF each, but
I'll try adding a second one to see if it helps."


Here is my analysis:

Trying to change your design to get out of illegal states is nearly pointless,
since
A) it is hard to do
B) the tools work against you
C) you may not catch all possible cases
D) by the time you detect it, damage has already been done
E) if the cause is gross signal integrity problems such as unreliable power, then
you FSM is the least of your problems.
(there are exceptions to this, such as remote systems (no one to push the reset
button, ultra high reliability systems (tolerates rare alpha particle upsets) )
Rickmans quote above is spot on.

Since this happens 10% of the time in a system at 20MHz, this is not metastability.

If you want to learn more about metastability, this is my favorite URL:

http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

Even though your problem is not metastability, once your current problem is fixed,
the much rarer problem of metastability may cause problems. A double synchronizer
on all your async inputs is cheap insurance.

You wrote: "I doubt that it's about static timing in my case since my clock
is 20 MHz, and XST's post-layout static timing analysis doesn't complain."

Your assertion that static timing analysis indicates that there are no problems
is insufficient. I have seen far too many designs by engineer that proudly show
the static timing report showing that there are no errors, but they have not
generated the "unconstrained paths" report. The static timing analyzer tells you
that of the paths you have constrained, these all meet timing, but the delay on
the unconstrained paths is unbounded. You need to identify all unconstrained
paths and either be able to explain why they dont need a timing constraint
(such as a push button input), or add constraints so that the paths are covered.

Phil Hays' quote above is almost certainly identifying your problem, and gives
a fine solution. Let me expand on it. The problem is that when the chip goes
active, you have logic signals that go into the state machine that cause it to
transition to a next state immediately. Since the going active is asynchronous
to the 20MHz clock, you may have anywhere from 50 to 0 ns to do this. This
represents a race condition (not a metastability), and in 10% of your startups,
you lose the race. As others have described, not all parts of the state machine
have enough time (when the available time is less than 50 ns) to transition to
the next valid state. Phil's (and Philip's) solution is to hold off the first
transitions of the state machine until a few cycles after the chip goes active.
Phil's solution suggests 15 cycles, probably anything over 4 would be rock solid.
As an example, I usually use a 4 bit shift register to do this. Either way, it
works like this:

The hold-off circuit is initialized to 0000 (counter or shifter). The release of
reset (chip going active) allows either to start changing. Phil's counter counts
up, in my case the D input to the shifter is tied high, so I start to shift in
'1's (0000->1000->1100->1110->1111->1111 ...)
For Phil's counter, you probably would want to make it dead-end at 1111, and not
wrap back to 0000.

Neither the counter or the shifter can't get to their terminal state other than
through multiple cycles of the clock.

In your FSM, the initial state is set in your VHDL. Depending on what your FSM
does the transition out of this state may be to one or more states. For ALL of
these exit conditions, you need to add an additional signal, the detection of
the terminal state of the hold-off circuit. The result is that the FSM cant
leave the initial state until several clocks after the chip goes active, because
the same logic that initializes the FSM, is also holding the hold-off circuit
in its initial state. By the time the FSM is allowed to make its first
transition, it will have stable input signals (through the double synchronizers)
and it will have a full cycle to do its transition.

Additional answers to some of your other questions:

"But your point is still interesting in case I would need to introduce an
asynchronous reset some day. Does that mean one should avoid them if illegal
states are a concern?"

Yes, you should avoid async signals and resets, regardless of whether you are
concerned about illegal states. If you must have broadly used resets, then the
common recommendation is async assertion, and sync de-assertion.

You wrote: "Metastability could be an issue, but it's strange that it happens so
often. On one particular design, it happens about once every ten times i
startup the system. All inputs are synchronized with one FF each, but
I'll try adding a second one to see if it helps."

Right. The 1 in 10 occurrence rate is far to high to be metastables in a system
running at 20MHz.

Your async inputs to the state machine should have at least a double synchronizer.
(read the above URL). The double synchronizers is just good design practice.


In summary:
Add the hold-off circuit, and check the unconstrained paths report in the static
timing analyzer.


Good Luck,

Philip

Philip Freidin
Fliptronics

 

[Jerker Hammarberg (DST)]

Each valid state will have a number of hold-until-next-move-true terms,
but states not covered will have NO .D terms, and so their NEXT state is
Q0.D = 0;
Q1.D = 0;
or to the 00 state.

If you code
IF State=11 THEN immediate_next = 00, then no more logic is generated,
as that is implicit.

All right, NOW I see your point! But it seems to me you're assuming that the
synthesis tool always generates the transition logic such that illegal
states always transition to the state vector of all zeroes, and I'm not yet
convinced that this is the case. I would have believed that the transition
function would map all illegal states to "Don't care", allowing the tool to
minimize the transition logic. As a consequence, the illegal states could
transition to anyting, including the same illegal state, which means it's
stuck. But I will try to investigate how XST generates the transition logic.
If you're right, you definitely answered my question no 2.

/Jerker

 

[INS122595]

At the ISE

Edit => Language Templates => VHDL => Component Instantiation => Block RAM

If you dont have the ISE download the WebPack from Xilinx site.

Walter.

"Oleg" <benkhalh@hotmail.com> a écrit dans le message de
news:5f8ab9cc.0407061824.330a99b@posting.google.com...

Hi, my question is very simple but i cant find any answer to it juste
loocking at xilinx site or reading there data sheets.
My question is :
Do any one have an exemple of template for instantiating xilinx Virtex
II single ported RAMB16_S2,RAMB16_9 and RAMB16_S18

 

[Philip Freidin]

On Thu, 08 Jul 2004 02:55:08 GMT, Philip Freidin <philip@fliptronics.com> wrote:

.... much good stuff ....

Neither the counter or the shifter can't get to their terminal state other than
through multiple cycles of the clock.

of course this should be:

Neither the counter or the shifter can get to their terminal state other than
through multiple cycles of the clock.


Philip

Philip Freidin
Fliptronics

 

[rickman]

Duane Clark wrote:

rickman wrote:

I am unclear as to why the others clause would not result in recovery
from an illegal state. That could very easily add a lot of extra logic
and even slow the max speed of the FSM. But it should not be optimized
away since it is a specified part of the machine. I assume the illegal
state detection works in simulation, no? If so, it should work in
operation.


The synthesis tools are "smart" enough to recognize that there is no
logical way to reach the "others" state. Therefore it is optimized out.
Many synthesis tools do this.

If this were true, then you would never need to specify that you are
using one-hot encoding. The states that are not used would be detected
as not needing to be decoded and the logic would automatically minimize
to just using one bit to represent each state. But I have seen guides
and HDL books explicitly tell you to either use an attribute to inform
the tool that you are using one-not encoding or to do the encoding
yourself by not using a case statement.

Where have you seen that a tool will optimize away the others clause? I
would like to read further on this. Are you talking about a FSM using
an enumerated data type? That would certainly not use the others clause
if all the listed values are covered.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

"Jerker Hammarberg (DST)" wrote:

Hi Rick, thanks for your reply!

1) electrical noise which would also cause upset of *other* FFs in the
system causing other symptoms and

I don't think I can rule that out in this specific application. But
where, that is on what physical signal, do you mean the electrical noise
would occur, and how could it affect the FPGA's internal state?

The noise could be on the power rail or ground bounce. It does not need
to be on an input signal.

2) timing issues with the FSM. This can be either from async inputs
(metastability) or from failing to meet setup time on a reg input. If
you have done your static timing analysis correctly, then it must be a
metastability issue. The fact that it occurs happens on startup says
to me it is a timing issue. If you can chase the problem away by
slowing your clock, then it is a static timing issue. If it persists,
then you most likely have a metastable issue.

I doubt that it's about static timing in my case since my clock is 20
MHz, and XST's post-layout static timing analysis doesn't complain.

That depends entirely on your timing specs. If you have none, then they
are not likely to be wrong XST will be trying to make every path
meet single clock timing.

Metastability could be an issue, but it's strange that it happens so
often. On one particular design, it happens about once every ten times i
startup the system. All inputs are synchronized with one FF each, but
I'll try adding a second one to see if it helps.

As others have suggested, if it fails on startup, it could easily be the
async reset vs. clock. I think you made two bad assumptions from the
way you describe your initial state. You indicated you used "initial
values by declarations". I don't think synthesis tools use initial
values as reset values. I have never asked if XST does this or not
since I don't depend on this. Accepted style is to put it explicitly in
your hdl code like this...

ByteFlag: process (SysClk, Reset) begin
if (Reset = '1') then
membyte <= '0';
elsif (rising_edge(SysClk)) then
if (set_byte = '1') then
membyte <= '1';
end if;
end if;
end process ByteFlag;

This code will use SysClk as the clock, Reset will init the FF to 0 and
set_byte will set the FF to a one. You can then use this signal as a
internal reset to other logic. Since it is synchronized it will allow
an FSM to get off on the right foot. You should not use the same signal
throughout your chip as it will most likely have significant routing
delay and miss setup times. Use a different copy for each FSM.

BTW, the Reset signal will sometimes automatically be connected to the
internal power on reset. It may require you to explicitly connect it
using an instantiated primative. Read up on XST and how it handles
resets.

I am not a fan of dealing with this type of problem by illegal state
recognition. If it gets into an illegal state it has already caused a
malfunction of the rest of the circuit most likely. Getting back to a
known state is only useful in that it can resume normal operation.
But it is not a "fix".

I agree totally, that's why I pointed out that most previous threads
dealt with recovery from but not with the cause of illegal states.

I am unclear as to why the others clause would not result in recovery
from an illegal state. That could very easily add a lot of extra
logic and even slow the max speed of the FSM. But it should not be
optimized away since it is a specified part of the machine. I assume
the illegal state detection works in simulation, no? If so, it should
work in operation.

Well, the FSM optimizer detects unreachable and removes related logic,
and I guess that's what's happening here too. Indeed, if I simulate the
RTL code as it is, I can't put the design in an illegal state - there is
simply no signal that I can force to an illegal value. But if I add a
dummy state in the enumerated state type definition without adding a
"when" clause for it, then I can enforce the dummy state and the "when
others" clause is applied. If I simulate the post-layout code, I would
be very surprised if the illegal state detection worked since it was
taken away during synthesis, but I haven't tried it.

You can directly force the FSM FFs into any state you wish. I have not
done it often, but I have used this feature. Read up on your simulator.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

"Jerker Hammarberg (DST)" wrote:

Hi Jim!

Do LOOK at the resultant output of your tools, and HOW it actually
built the FSM. It can use .D or .T registers, with .D the most common.

Well, the output netlist isn't exactly human-readable, although I guess
I could write a simple FSM, synthesize it and study it. But actually I
already know how XST has encoded my machine. My options are essentially
One-Hot, Compact (binary), Sequential, Gray, and Johnson, all presumably
on D flip-flops. I get One-Hot encoded machines unless i ask for
something else.

However, correct me if I'm wrong, the state encoding itself doesn't
change anything in the machine's ability to recover from illegal states
- it takes some logic that detects these illegal states and forces the
state vector back to normal, and that logic obviously isn't there. Many
synthesis tools provide an extra option "safe FSMs" which will add such
logic, but XST doesn't. So my question is XST-specific - how do I add
illegal state recovery logic with XST?

One other thing you can do is to add the logic manually. If you are
using an enumerated data type, you can get the encoded value. Write
your own logic on this state value and detect the illegal combinations.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jerker Hammarberg (DST)]

Hi Philip, and thank you for your enlightening and extensive reply!

From reading your various postings, I believe the summary is:

You have a state machine.
It gets into illegal states.
It does it about 1 out of 10 times on startup.
You do not have an async reset to the FSM.
Your async inputs to the state machine go through a single flipflop.
You are investigating ways of detecting illegal states and want to get
back to a valid state.
You specify initial values (in VHDL).
Your static timing analysis indicates no problems.
Your clock frequency is 20MHz.

Right, I should say that this design with 20MHz and 1 out of 10 failure
rate is just one of several designs that I have problems with. I don't
only want to solve the problem for that particular one design; I want to
learn as much as possible about this issue, so that I can solve the
problem for all my designs and avoid it in the future.

For that 20MHz design, I could add that it doesn't seem to happen when
the board's power supply is less loaded. Considering that it almost
always happens on startup, when components all over the board need a lot
of current, I suspect it might have something to do with voltage dips.
But I don't see why that would only result in a state machine hanging; I
would expect to see more diverse errors. Whatsoever I will examine the
voltage curve on powerup.

If you want to learn more about metastability, this is my favorite
URL:
http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

Even though your problem is not metastability, once your current
problem is fixed, the much rarer problem of metastability may cause
problems. A double synchronizer on all your async inputs is cheap
insurance.

I actually read the faq before posting, like a good newsgroup poster
should do! I will add a second synchronizer, but it hurts a little,
because one of the inputs is an SPI clock and the FPGA is supposed to
react as fast as possible on its edges.

You wrote: "I doubt that it's about static timing in my case since my
clock is 20 MHz, and XST's post-layout static timing analysis doesn't
complain."

Your assertion that static timing analysis indicates that there are no
problems is insufficient. I have seen far too many designs by engineer
that proudly show the static timing report showing that there are no
errors, but they have not generated the "unconstrained paths" report.
The static timing analyzer tells you that of the paths you have
constrained, these all meet timing, but the delay on the unconstrained
paths is unbounded. You need to identify all unconstrained paths and
either be able to explain why they dont need a timing constraint (such
as a push button input), or add constraints so that the paths are
covered.

I have to admit I haven't cared much about static timing, since I
believed that if I specify a clock period constraint, all FF to FF paths
would be constrained by this time, and that's all I need in a completely
synchronous design. Is that wrong? Anyway, I realize that I need to
learn more about timing... or finally tell my boss I shouldn't be doing
FPGA design without proper education.

I will check the unconstrained paths, but I expect to find only input to
FF and FF to output paths. I don't care about output delay since they
are only connected to leds and SPI units working at a considerably
slower rate. In particular, these paths can't affect my state machines.
And the inputs can arrive anytime anyway. Would you agree that given
this, I could rule out timing issues (apart from the following)?

Phil Hays' quote above is almost certainly identifying your problem,
and gives a fine solution. Let me expand on it. The problem is that
when the chip goes active, you have logic signals that go into the
state machine that cause it to transition to a next state immediately.
Since the going active is asynchronous to the 20MHz clock, you may
have anywhere from 50 to 0 ns to do this. This represents a race
condition (not a metastability), and in 10% of your startups, you lose
the race. As others have described, not all parts of the state machine
have enough time (when the available time is less than 50 ns) to
transition to the next valid state. Phil's (and Philip's) solution is
to hold off the first transitions of the state machine until a few
cycles after the chip goes active. Phil's solution suggests 15 cycles,
probably anything over 4 would be rock solid. As an example, I usually
use a 4 bit shift register to do this. Either way, it works like this:

This was totally new to me. I take it ALL state machines that may
transition on the first clock pulse need this kind of protection.

Thanks again, Philip (and Phil)!

/Jerker

 

[Jerker Hammarberg (DST)]

One other thing you can do is to add the logic manually. If you are
using an enumerated data type, you can get the encoded value. Write
your own logic on this state value and detect the illegal
combinations.

I'm not so sure... again, XST finds all unreachable states and takes
away the logic for them, even states that are legal and have their own
"when" clause. I've even seen in another thread on comp.lang.vhdl the
suggestion to connect an input pin to ground, then add code to the state
machine like

if ground_signal = '1' then
state <= UNREACHABLE_STATE;
end if;

just to prevent XST from taking away the logic for UNREACHABLE_STATE.
But I was hoping there were better solutions...

/Jerker

 

[Jerker Hammarberg (DST)]

Or maybe you mean I should add separate logic outside of the state
machine? That could work... I'll try that.

/Jerker

 

[Just an Illusion]

Hi Rakesh,

See thread 'mixed Verilog/VHDL design' from botao.
You can find some possible solutions.

JaI

Rakesh YC wrote:

Hi All
My problem is I'd like to choose VHDL entity instantiated in verilog module
via a VHDL configuration

To summerize: I have a hierarcy "top:vhdl - verilog - verilog - vhdl:bottom"
structure. How to write a vhdl configuration to select the file for the bottom
instantiation?

If such vhdl configuration type is not possible, any suggestions to solve
this?

Rakesh YC

 

[Jonathan Bromley]

On 9 Jul 2004 06:51:28 -0700, ALuPin@web.de (ALuPin) wrote:

Given one signal "l_data" which is created in a clock synchronous process.

As an concurrent assignment I have the following:

l_data_help <= l_data;
l_data_help(4) <= NOT l_data(4);

When compiling that Modelsim does NOT show any warning although it is
a multiple source.

Am I right?

If l_data_help is a STD_LOGIC_VECTOR then there is no problem with
multiple drivers on it; however, your code will always drive it to
'U' or 'X'.

Similarly, if the elements of l_data_help are of ANY resolved type,
your code is legal (but probably not useful).

On the other hand, if the elements of l_data_help are of unresolved
type, the simulator should detect the error at elaboration time.
At compile time it is NOT required to detect the error, although
it wll probably give a warning in this case where both drivers
exist in the same design unit.

As an experiment, try re-defining l_data and l_data_help to be
STD_ULOGIC_VECTOR instead of STD_LOGIC_VECTOR.
--
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.

 

[Nicolas Matringe]

Jonathan Bromley a écrit:

On the other hand, if the elements of l_data_help are of unresolved
type, the simulator should detect the error at elaboration time.
At compile time it is NOT required to detect the error, although
it wll probably give a warning in this case where both drivers
exist in the same design unit.

As an experiment, try re-defining l_data and l_data_help to be
STD_ULOGIC_VECTOR instead of STD_LOGIC_VECTOR.

ModelSim won't give any warning or error at compile time (I've already
posted about this a few weeks ago)
I didn't know at the time that the error detection was due at
elaboration time.

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

 

[Duane Clark]

rickman wrote:

If this were true, then you would never need to specify that you are
using one-hot encoding. The states that are not used would be detected
as not needing to be decoded and the logic would automatically minimize
to just using one bit to represent each state...

Yes, I am talking about one-hot encoding. Where I have seen the problem
is on power when, for whatever reason, none of the states are selected.
In that case, the state machine is dead.

Where have you seen that a tool will optimize away the others clause?

Xilinx XST.

--
My real email is akamail.com@dclark (or something like that).

 

[Duane Clark]

Duane Clark wrote:

Yes, I am talking about one-hot encoding. Where I have seen the problem
is on power...

Uggh, that should say power-on.

--
My real email is akamail.com@dclark (or something like that).

 

[rickman]

"Jerker Hammarberg (DST)" wrote:

That depends entirely on your timing specs. If you have none, then
they are not likely to be wrong XST will be trying to make every
path meet single clock timing.

Sure! I have specified a clock period constraint, which I thought would
be enough. See further my reply to Philip.

As others have suggested, if it fails on startup, it could easily be
the async reset vs. clock. I think you made two bad assumptions from
the way you describe your initial state. You indicated you used
"initial values by declarations". I don't think synthesis tools use
initial values as reset values. I have never asked if XST does this
or not since I don't depend on this. Accepted style is to put it
explicitly in your hdl code like this...

But this is a well documented feature in XST, see XST User guide,
Chapter 6, Initial Values. It says "When you give a register an initial
value in a declaration, XST sets this value on the output of the
register at global reset, or at power up.". So if the feature is there,
it must be OK to use it, and to skip explicit resets?

Ok, if you are sure this works for XST, then that is ok. But it won't
work with other synthesis tools which will make your code not portable.
If you later want to use a better tool, you will have to go back and use
the standard method on every signal you are initializing.

Either way, if it is being reset, then that is covered. But this does
not necessarily mean it will come out of reset correctly. Since the
clock is async with respect to the reset, and the reset has variable
delays throughout the chip, you can release reset on different parts of
the chip (including different FFs in the same state machine) on
different clock cycles.

One way to fix this is to make sure the global reset path delay is less
than one clock cycle and to sync the reset to the global clock. I
believe there is a config bit stream option to synchonize the end of
reset with your global clock. Check the docs. This is something you
will set when you generate the bit stream. I am not sure how to find
out how long the reset delay paths are.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[DrB]

Phil

Your allusion to "common" DCM / DLL issues has aroused my curiosity.

Could you elucidate please.

Martin


"Phil Hays" <Spampostmaster@comcast.net> wrote in message
news:imsoe05ptq3h66j0m4t0ha1dqsdrure8j3@4ax.com...

"Jerker Hammarberg (DST)" <jerkerNO@SPAMdst.se> wrote:

How is the reset signal handled? If the FFs are asynchronously reset,
then the end of reset can happen at different times to different FFs,
leading to an illegal state.

Hi Phil! I use no reset signal at all; instead I specify initial values
for all signals by the declarations, which is supposed to work fine with
XST.

You do have an asynchronous reset, you just didn't know that you did.
When a Xilinx FPGA finishes the program download, it has all initial
values held until an internal signal is released. This release is
asynchronous to your clock. To avoid problems with this add a counter
that is reset to all zeros. Until that counter counts to 15, keep the
state machine in the initial state.

(Note: Startup is a messy subject. This is a simplified version.)

There is another common issue with DCMs or DLLs that you might also be
having a problem with. Are you using a DCM or a DLL?


But your point is still interesting in case I would need to
introduce an asynchronous reset some day. Does that mean one should
avoid them if illegal states are a concern?

Yes. Suppose the initial state is "100" and the desired next state is
"010". This would be a three state one-hot machine.
If the first bit is held until just after the first edge of the clock
and the second bit is held until just before the first edge of the
clock, then the next state will be illegal, "110".
If the first bit is held until just before the first edge of clock and
the second bit is held until just after the first edge of the clock,
then the next state will be illegal, "000".

Does that make it clear?


--
Phil Hays
Phil-hays at posting domain should work for email

 

[David de Andrés Martínez]

ALuPin wrote:

Hi,

does someone know links to FPGA/CPLD related sites about
VHDL design of VGA controller, hsync, vsync, composite sync in general ?

I would appreciate your help.

Kind regards

Take a look at the projects of the Queensland University
http://www.itee.uq.edu.au/~peters/xsvboard/

Best regards

 

[Phil Hays]

On Mon, 12 Jul 2004 10:26:21 +0100, "DrB" <nospam@nospam.no> wrote:

There is another common issue with DCMs or DLLs that you might also be
having a problem with. Are you using a DCM or a DLL?

Your allusion to "common" DCM / DLL issues has aroused my curiosity.

Sure. I'm not sure "common" was the correct word, but I suspected
that the original poster might have run into the following issue.
I've seen it in someone else's design. These problems are curable by
reading the fine manual (RTFM).

RTFM # 1 "Do not use the DCM output clock signals until after
activation of the LOCKED signal. Prior to the activation of the LOCKED
signal, the DCM output clocks are not valid and can exhibit glitches,
spikes, or other spurious movement."

You can keep the part in configuration until the DCMs are locked by a
bitgen option, or you can use the synchronized locked signal to force
reset to all state machines and all other critical logic. Better do
one of the two. The bitgen option is probably best, unless you may be
resetting the DCMs after configuration, in which case you need to do
the second.


I didn't think he had this issue, but I've seen it as well. In my own
design.

RTFM # 2 "To ensure consistent locking, if a DCM is configured with
external feedback, applying a reset after configuration is strongly
recommended."

"Strongly recommended" isn't quite correct. "Required" would be
better wording.


--
Phil Hays
Phil-hays at posting domain should work for email