odd behaviour

[andy]

Hi, I’m experiencing some odd behaviour in what was previously a
static/working design in a Xilinx cpld. The circuit handles the
arbitration between dsp and peripherals. The problem is I have some
signals that appear to behave differently when the project is simply
synthesised and run through place and route.

For example the following process does not get asserted as expected
when addressed by the dsp. When rebuilt with the testpoints included
to break out to a scope the circuit works as expected.

writeCycle: process ( clk, rst )
begin
if ( rst = '1' ) then
output <= '0';
--Test1 <= '0';
elsif Rising_edge ( clk ) then
if ( rw = '0' ) then
if ( IntAddress = Addr ) then
--Test1 <= '1';
output <= ‘1’;
end if;
end if;
end if;
end process writeCycle;

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

All very odd! It’s a stab in the dark but has anyone experienced
anything similar?

thanks

 

[Mike Treseler]

andy wrote:

All very odd! It’s a stab in the dark but has anyone experienced
anything similar?

Yes. Maybe rw is not synchronized to clk
or the static timing Fmax(clk) < the clock frequency.

-- Mike Treseler

 

[KJ]

On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:
<snip>

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

All very odd! It’s a stab in the dark but has anyone experienced
anything similar?

Odd behavior is almost always a symptom of failing timing in some
fashion. In your code snippet, my first question would be are ALL of
the following signals synchronized to clk?

rst, rw, IntAddress, Addr

If not, then they need to be since they are all used as inputs to a
synchronous process.

If they are, then have the appropriate setup delays been added and
timing analysis been run? Did it pass?

Kevin Jennings

 

[andy]

On Jul 10, 4:45 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:
snip

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

All very odd! It’s a stab in the dark but has anyone experienced
anything similar?

Odd behavior is almost always a symptom of failing timing in some
fashion.  In your code snippet, my first question would be are ALL of
the following signals synchronized to clk?

rst, rw, IntAddress, Addr

If not, then they need to be since they are all used as inputs to a
synchronous process.

If they are, then have the appropriate setup delays been added and
timing analysis been run?  Did it pass?

Kevin Jennings

Thanks for the feedback guys, the only asynchronous signal is rst,
this is an input from some external supervisory cct, i want to
maintain this as i dont want external signals in an undefined state
before clk is stable. clk, rw and Addr are all synchronous. One thing
is that IntAddress is a type conversion of the actual input
address...Not sure if this would cause any issues, the qualification
is all zero wait state

My concern is that any design changes made overcome the problems seen,
unfortunately this includes re-building the existing project without
any changes. This makes me wonder if i've really addressed the
underlined problem.

 

[Tricky]

On 11 Jul, 08:45, andy <astubb...@baldor.com> wrote:

On Jul 10, 4:45 pm, KJ <kkjenni...@sbcglobal.net> wrote:



On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:
snip

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

All very odd! It’s a stab in the dark but has anyone experienced
anything similar?

Odd behavior is almost always a symptom of failing timing in some
fashion.  In your code snippet, my first question would be are ALL of
the following signals synchronized to clk?

rst, rw, IntAddress, Addr

If not, then they need to be since they are all used as inputs to a
synchronous process.

If they are, then have the appropriate setup delays been added and
timing analysis been run?  Did it pass?

Kevin Jennings

Thanks for the feedback guys, the only asynchronous signal is rst,
this is an input from some external supervisory cct, i want to
maintain this as i dont want external signals in an undefined state
before clk is stable. clk, rw and Addr are all synchronous. One thing
is that IntAddress is a type conversion of the actual input
address...Not sure if this would cause any issues, the qualification
is all zero wait state

My concern is that any design changes made overcome the problems seen,
unfortunately this includes re-building the existing project without
any changes. This makes me wonder if i've really addressed the
underlined problem.

Instead of putting "Test1" inside the process itself, attach it to
output outside the process. The problem with the current method is you
will be generating two separate registers (which may or may not be
synthesized into a single register). This may be why sometimes it
works sometimes it doesnt.

Also, are you sure you want the output latched to a '1' until the
asynch reset is asserted? it may be a problem with the reset
assertion. As it is asynchrounous, you cannot guarantee that the reset
will go low long enough before the next clock edge which may then try
to set output to a '1', which will give you metastability. It may be a
good idea to synchronise the reset signal to the clk, as you will
avoid this.

Another thought - look at the mapped view post P&R to make sure it
hasnt done something silly like bring clk and/or reset off their
respective high speed net's into a LUT and used them as logic inputs
pre-register. (very unlikely, as this is a standard clocked process
template, but as this is more of an SR latch than a normal D-type, you
never know)

 

[KJ]

On Jul 11, 3:45 am, andy <astubb...@baldor.com> wrote:

On Jul 10, 4:45 pm, KJ <kkjenni...@sbcglobal.net> wrote:





On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:
snip

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

All very odd! It’s a stab in the dark but has anyone experienced
anything similar?

Odd behavior is almost always a symptom of failing timing in some
fashion.  In your code snippet, my first question would be are ALL of
the following signals synchronized to clk?

rst, rw, IntAddress, Addr

If not, then they need to be since they are all used as inputs to a
synchronous process.

If they are, then have the appropriate setup delays been added and
timing analysis been run?  Did it pass?

Kevin Jennings

Thanks for the feedback guys, the only asynchronous signal is rst,
this is an input from some external supervisory cct, i want to
maintain this as i dont want external signals in an undefined state
before clk is stable.

Unless rst is glitchy, I don't think this is your problem, but you're
missing the point when it comes to rst. Since it comes in
asynchronous to the clock, what makes you think you'll end up in the
correct state when rst goes away if it happens to go away within the
setup time of the flip flop? That flop could go to either a '1' or a
'0' depending on the logic and precisely when rst goes away relative
to clk. Maybe it doesn't matter much for this particular process, but
any state machine or other clocked logic that is in your current
design may not like it very well and fail in odd ways.

The thing to think about is NOT what flops are doing when rst is
active, but what happens when rst is going away...and where does it go
away relative to the clock?
Hint1: Setup and hold times are requirements that must be met for
proper operation, not just nice to haves.

Hint2: No signal arrives at precisely the same time at two different
places, so two random flops in your CPLD will see 'rst' at slightly
different times.

The way you handle this is the same way you handle any asynchronous
input, you synchronize first into one and only one flop then use the
output of that flop. Generally people use two stage synchronizers in
order to reduce the effects of metastability.

clk, rw and Addr are all synchronous.

Well, how you think 'clk' can be synchronous is a mystery...maybe a
typo on your part. It appeared from your original post that rw and
Addr were coming in from external I/O pins, and now you've added that
they are synchronous. Since they are synchronous to clk you don't
need to synchronize them but that doesn't mean that there is no timing
analysis needed. To perform timing analysis you need to take the
following into account at a bare minimum:

- What is the clock skew between your CPLD and the external device
that generates rw and Addr (Call that Tskew).
- What is the clock to output delay between clk and rw as well as
between clk and Addr? (Call the larger of the two Tco).
- From the CPLD timing report, what is the setup time requirement for
rw and Addr relative to clk? (Call the larger of the two Tsu)

Now plug in the numbers and verify that you meet the following timing
requirement
Tsu < T - Tskew - Tco (where T=minimum clock period)

Repeat this process for every input to your CPLD.

Generally speaking, one would enter a setup time requirement into the
CPLD synthesis tools so that when it performs the timing analysis it
will tell you whether it has detected any timing violations. However,
even if you don't, it will produce a report telling you what the setup
time is and you can use that to calculate whether you have a problem
or not.

The other aspect of this is that your CPLD has outputs and those
outputs probably have requirements that must be met by the devices
that receieve those outputs. You do the same basic analysis but now
you're solving for Tco in order to determine what the clock to output
delay requirement that your CPLD must meet should be.

One thing
is that IntAddress is a type conversion of the actual input
address...

Not relevant.

Not sure if this would cause any issues, the qualification
is all zero wait state

You're focusing on the wrong things, you most likely have a timing
problem and you're not presenting anything to indicate that you've
performed any sort of timing analysis.

The other obvious timing thing to check from the CPLD timing report is
that the clock frequency that it computed your design can run at is
greater than the clock frequency of the actual clock used. Again, one
would normally enter that in as a timing constraint to the CPLD
synthesis tool to tell it that 'clk' has a requirement of say 100
MHz. That way it will flag it as a timing problem if it can't achieve
that number.

My concern is that any design changes made overcome the problems seen,
unfortunately this includes re-building the existing project without
any changes. This makes me wonder if i've really addressed the
underlined problem.- Hide quoted text -

Since the underlying problem is (with nearly 100% certainty) a timing
problem, the lack of timing analysis on your part would indicate to me
that you have not addressed the underlying problem. The analysis
isn't hard, but it is important. Failure to do so means you're
counting on luck to get you through...since you've seen your design
fail, your luck has run out.

Kevin Jennings

 

[rickman]

On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:

Hi, I’m experiencing some odd behaviour in what was previously a
static/working design in a Xilinx cpld. The circuit handles the
arbitration between dsp and peripherals. The problem is I have some
signals that appear to behave differently when the project is simply
synthesised and run through place and route.

For example the following process does not get asserted as expected
when addressed by the dsp. When rebuilt with the testpoints included
to break out to a scope the circuit works as expected.

writeCycle: process ( clk, rst )
begin
if ( rst = '1' ) then
output <= '0';
--Test1 <= '0';
elsif Rising_edge ( clk ) then
if ( rw = '0' ) then
if ( IntAddress = Addr ) then
--Test1 <= '1';
output <= ‘1’;
end if;
end if;
end if;
end process writeCycle;

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

You refer to the circuit working as "expected". What is the
"expected" operation? If you think this circuit is going to do
anything other than set the output the first time it is addressed,
then maybe you are expecting something different from what you have
written. Other than the reset behavior, you only define one action,
setting the FF to a 1 when addressed. So the FF starts in the 0 state
when reset and remains there until addressed. Then it changes to a 1
and remains there until reset again. Is this what you "expected"???

Or were you trying to describe a circuit that outputs a synchronous
signal that outputs a 1 *while* addressed and returns to a 0 when the
address cycle is over? If so, you need to change the code like this
perhaps.

writeCycle: process ( clk, rst )
begin
if ( rst = '1' ) then
output <= '0';
--Test1 <= '0';
elsif Rising_edge ( clk ) then
output <= ‘0’; -- default behavior when not addressed
if ( rw = '0' ) then
if ( IntAddress = Addr ) then
--Test1 <= '1';
output <= ‘1’;
end if;
end if;
end if;
end process writeCycle;

If I am off base, then please explain what you expect it to do and
what you are seeing it do. Also, when is it failing? Your
description above says it fails and then works ok when you add the
test point, then it works ok when you remove the test point. Are you
saying that it is not working ok and you add signals to debug it.
Then after that it work ok even when the debugging info is removed?

BTW, I am using Synplify with Lattice parts and I have seen it
synthesis badly, then a trivial change to the code makes it work
correctly. Meanwhile it works just fine in simulation. My design is
running with a rather slow clock (12 MHz), so I don't expect it is
timing. The malfunction is not easily explained by a timing error
either, but then maybe I am just not looking hard enough. I was
thinking more of an issue with an unintentional async loop. I have a
number of muxes and there may be an async loop from those.


Rick

 

[andy]

On Jul 11, 1:25 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Jul 11, 3:45 am, andy <astubb...@baldor.com> wrote:





On Jul 10, 4:45 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:
snip

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

All very odd! It's a stab in the dark but has anyone experienced
anything similar?

Odd behavior is almost always a symptom of failing timing in some
fashion. In your code snippet, my first question would be are ALL of
the following signals synchronized to clk?

rst, rw, IntAddress, Addr

If not, then they need to be since they are all used as inputs to a
synchronous process.

If they are, then have the appropriate setup delays been added and
timing analysis been run? Did it pass?

Kevin Jennings

Thanks for the feedback guys, the only asynchronous signal is rst,
this is an input from some external supervisory cct, i want to
maintain this as i dont want external signals in an undefined state
before clk is stable.

Unless rst is glitchy, I don't think this is your problem, but you're
missing the point when it comes to rst. Since it comes in
asynchronous to the clock, what makes you think you'll end up in the
correct state when rst goes away if it happens to go away within the
setup time of the flip flop? That flop could go to either a '1' or a
'0' depending on the logic and precisely when rst goes away relative
to clk. Maybe it doesn't matter much for this particular process, but
any state machine or other clocked logic that is in your current
design may not like it very well and fail in odd ways.

The thing to think about is NOT what flops are doing when rst is
active, but what happens when rst is going away...and where does it go
away relative to the clock?
Hint1: Setup and hold times are requirements that must be met for
proper operation, not just nice to haves.

Hint2: No signal arrives at precisely the same time at two different
places, so two random flops in your CPLD will see 'rst' at slightly
different times.

The way you handle this is the same way you handle any asynchronous
input, you synchronize first into one and only one flop then use the
output of that flop. Generally people use two stage synchronizers in
order to reduce the effects of metastability.

clk, rw and Addr are all synchronous.

Well, how you think 'clk' can be synchronous is a mystery...maybe a
typo on your part. It appeared from your original post that rw and
Addr were coming in from external I/O pins, and now you've added that
they are synchronous. Since they are synchronous to clk you don't
need to synchronize them but that doesn't mean that there is no timing
analysis needed. To perform timing analysis you need to take the
following into account at a bare minimum:

- What is the clock skew between your CPLD and the external device
that generates rw and Addr (Call that Tskew).
- What is the clock to output delay between clk and rw as well as
between clk and Addr? (Call the larger of the two Tco).
- From the CPLD timing report, what is the setup time requirement for
rw and Addr relative to clk? (Call the larger of the two Tsu)

Now plug in the numbers and verify that you meet the following timing
requirement
Tsu < T - Tskew - Tco (where T=minimum clock period)

Repeat this process for every input to your CPLD.

Generally speaking, one would enter a setup time requirement into the
CPLD synthesis tools so that when it performs the timing analysis it
will tell you whether it has detected any timing violations. However,
even if you don't, it will produce a report telling you what the setup
time is and you can use that to calculate whether you have a problem
or not.

The other aspect of this is that your CPLD has outputs and those
outputs probably have requirements that must be met by the devices
that receieve those outputs. You do the same basic analysis but now
you're solving for Tco in order to determine what the clock to output
delay requirement that your CPLD must meet should be.

One thing
is that IntAddress is a type conversion of the actual input
address...

Not relevant.

Not sure if this would cause any issues, the qualification
is all zero wait state

You're focusing on the wrong things, you most likely have a timing
problem and you're not presenting anything to indicate that you've
performed any sort of timing analysis.

The other obvious timing thing to check from the CPLD timing report is
that the clock frequency that it computed your design can run at is
greater than the clock frequency of the actual clock used. Again, one
would normally enter that in as a timing constraint to the CPLD
synthesis tool to tell it that 'clk' has a requirement of say 100
MHz. That way it will flag it as a timing problem if it can't achieve
that number.

My concern is that any design changes made overcome the problems seen,
unfortunately this includes re-building the existing project without
any changes. This makes me wonder if i've really addressed the
underlined problem.- Hide quoted text -

Since the underlying problem is (with nearly 100% certainty) a timing
problem, the lack of timing analysis on your part would indicate to me
that you have not addressed the underlying problem. The analysis
isn't hard, but it is important. Failure to do so means you're
counting on luck to get you through...since you've seen your design
fail, your luck has run out.

Kevin Jennings- Hide quoted text -

- Show quoted text -

KJ, my apologies for trying to explain the problem too simplistically
and leaving out vital information (thanks for telling me off ƒź).

The sytem clock is 60Mhz, I have period constraints for the design set
at 16.67ns with setup and hold times of 10 and 14ns respectively. I
get no failing paths indicated in the timing report. The max clk freq
is set to 100MHz with clk to setup (Tcyc) 6.6ns, pad to pad delay
(Tpd) 11.4ns, setup to clk at pad (Tsu) 4.7ns and clk pad to output
delay (Tco) 17.2ns.
The signals that have the Tco of 17.2ns are multicycle paths so should
not be the cause of the problem.

I agree with you that this smacks of a timing issue as all register
access were zero wait state and by changing to one all my problems
appear to go away. My concern is that I'm not actually meeting setup/
hold but I'm not getting any warnings about it, which is why I also
wonder if I have actually addressed the real issue.

Including the clk in the synchronous statement was a typo, again my
apologies.

The reset is active for 150ms after power up and I would have thought
this plenty of time to ensure the state of all flops before becoming
in-active.

Andy

 

[andy]

On Jul 12, 5:36 am, rickman <gnu...@gmail.com> wrote:

On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:





Hi, I’m experiencing some odd behaviour in what was previously a
static/working design in a Xilinx cpld. The circuit handles the
arbitration between dsp and peripherals. The problem is I have some
signals that appear to behave differently when the project is simply
synthesised and run through place and route.

For example the following process does not get asserted as expected
when addressed by the dsp. When rebuilt with the testpoints included
to break out to a scope the circuit works as expected.

  writeCycle: process ( clk, rst )
  begin
    if ( rst = '1' ) then
        output        <= '0';
                --Test1         <= '0';
    elsif Rising_edge ( clk ) then
      if ( rw = '0' ) then
        if ( IntAddress = Addr ) then
        --Test1         <= '1';
                output <= ‘1’;
        end if;
      end if;
    end if;
end process writeCycle;

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

You refer to the circuit working as "expected".  What is the
"expected" operation?  If you think this circuit is going to do
anything other than set the output the first time it is addressed,
then maybe you are expecting something different from what you have
written.  Other than the reset behavior, you only define one action,
setting the FF to a 1 when addressed.  So the FF starts in the 0 state
when reset and remains there until addressed.  Then it changes to a 1
and remains there until reset again.  Is this what you "expected"???

Or were you trying to describe a circuit that outputs a synchronous
signal that outputs a 1 *while* addressed and returns to a 0 when the
address cycle is over?  If so, you need to change the code like this
perhaps.





  writeCycle: process ( clk, rst )
  begin
    if ( rst = '1' ) then
        output        <= '0';
                --Test1         <= '0';
    elsif Rising_edge ( clk ) then
      output <= ‘0’;  -- default behavior when not addressed
      if ( rw = '0' ) then
        if ( IntAddress = Addr ) then
        --Test1         <= '1';
                output <= ‘1’;
        end if;
      end if;
    end if;
end process writeCycle;

If I am off base, then please explain what you expect it to do and
what you are seeing it do.  Also, when is it failing?  Your
description above says it fails and then works ok when you add the
test point, then it works ok when you remove the test point.  Are you
saying that it is not working ok and you add signals to debug it.
Then after that it work ok even when the debugging info is removed?

BTW, I am using Synplify with Lattice parts and I have seen it
synthesis badly, then a trivial change to the code makes it work
correctly.  Meanwhile it works just fine in simulation.  My design is
running with a rather slow clock (12 MHz), so I don't expect it is
timing.  The malfunction is not easily explained by a timing error
either, but then maybe I am just not looking hard enough.  I was
thinking more of an issue with an unintentional async loop.  I have a
number of muxes and there may be an async loop from those.

Rick- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Rickman, your first description is correct. The signal is used as a
one time enable line to an internal component. I’ve a logic analyser
on all the external adrs, data and relevant control strobes to ensure
everything is as it should be. The problem was with one particular
build the signal was not being set when all the external signals were
present and correct. I simply added the test signal to break out the
signal to and external pin and the problem went away, I then removed
the testpoint from the process and the problem did not re-materialise.

 

[KJ]

On Jul 14, 4:57 am, andy <astubb...@baldor.com> wrote:

On Jul 11, 1:25 pm, KJ <kkjenni...@sbcglobal.net> wrote:


The sytem clock is 60Mhz, I have period constraints for the design set
at 16.67ns with setup and hold times of 10 and 14ns respectively.

Those constraints makes no sense. How can you have a setup/hold
window of 24 ns and a clock period of 16.7 ns?

I
get no failing paths indicated in the timing report. The max clk freq
is set to 100MHz with clk to setup (Tcyc) 6.6ns, pad to pad delay
(Tpd) 11.4ns, setup to clk at pad (Tsu) 4.7ns and clk pad to output
delay (Tco) 17.2ns.
The signals that have the Tco of 17.2ns are multicycle paths so should
not be the cause of the problem.

And you've done the timing analysis that shows that the other parts in
the system would work with these delays? On the surface it seems like
it wouldn't. The setup and hold time that you got add up to 11.3 ns
leaving at best another 5.4 ns for any other device for its clock to
output and setup time...and it seems that there are at least a couple
of external devices to consider (DSP, memory??)

I agree with you that this smacks of a timing issue as all register
access were zero wait state and by changing to one all my problems
appear to go away. My concern is that I'm not actually meeting setup/
hold but I'm not getting any warnings about it, which is why I also
wonder if I have actually addressed the real issue.

Based on your first sentence in this post, I get the impression that
you haven't properly input the timing requirements into the tool. If
that's the case, then the lack of any failing paths being reported is
irrelevant. I'd suggest that you sketch out on paper the complete
timing path of your system (DSP, FPGA, memory, other stuff??). Use
the Tco/Tsu/Th from the device specs and the FPGA report of what it
achieved and see if such a system completes what it needs to in the
16.7 ns available. Also, you might want to put a scope on the clk
inputs of the various devices and measure what sort of clock skew you
may have between devices since that will factor into the timing
analysis as well as I mentioned in my previous post.

The reset is active for 150ms after power up and I would have thought
this plenty of time to ensure the state of all flops before becoming
in-active.

Again, reset is a side issue, but you're still missing the point. It
doesn't matter if reset is there for 2 ns, 150 ms or 2.5 weeks. Yes
the flops will get reset. But at *some point* reset will go
away...and if it goes away 1 ns before the rising edge of a clock and
the PLD has a setup time requirement of 1.5 ns, what makes you think
that that flop will remain in the state that you reset it to?

KJ

 

[rickman]

On Jul 14, 4:57 am, andy <astubb...@baldor.com> wrote:

On Jul 12, 5:36 am, rickman <gnu...@gmail.com> wrote:



On Jul 10, 10:25 am, andy <astubb...@baldor.com> wrote:

Hi, I’m experiencing some odd behaviour in what was previously a
static/working design in a Xilinx cpld. The circuit handles the
arbitration between dsp and peripherals. The problem is I have some
signals that appear to behave differently when the project is simply
synthesised and run through place and route.

For example the following process does not get asserted as expected
when addressed by the dsp. When rebuilt with the testpoints included
to break out to a scope the circuit works as expected.

writeCycle: process ( clk, rst )
begin
if ( rst = '1' ) then
output <= '0';
--Test1 <= '0';
elsif Rising_edge ( clk ) then
if ( rw = '0' ) then
if ( IntAddress = Addr ) then
--Test1 <= '1';
output <= ‘1’;
end if;
end if;
end if;
end process writeCycle;

Once the tespoint has been removed and the project re-synthesised and
run through place and route the ouput works as expected. Unfortunately
i've had this happen in two areas of the design now and i'm out of
ideas.

You refer to the circuit working as "expected". What is the
"expected" operation? If you think this circuit is going to do
anything other than set the output the first time it is addressed,
then maybe you are expecting something different from what you have
written. Other than the reset behavior, you only define one action,
setting the FF to a 1 when addressed. So the FF starts in the 0 state
when reset and remains there until addressed. Then it changes to a 1
and remains there until reset again. Is this what you "expected"???

Or were you trying to describe a circuit that outputs a synchronous
signal that outputs a 1 *while* addressed and returns to a 0 when the
address cycle is over? If so, you need to change the code like this
perhaps.

writeCycle: process ( clk, rst )
begin
if ( rst = '1' ) then
output <= '0';
--Test1 <= '0';
elsif Rising_edge ( clk ) then
output <= ‘0’; -- default behavior when not addressed
if ( rw = '0' ) then
if ( IntAddress = Addr ) then
--Test1 <= '1';
output <= ‘1’;
end if;
end if;
end if;
end process writeCycle;

If I am off base, then please explain what you expect it to do and
what you are seeing it do. Also, when is it failing? Your
description above says it fails and then works ok when you add the
test point, then it works ok when you remove the test point. Are you
saying that it is not working ok and you add signals to debug it.
Then after that it work ok even when the debugging info is removed?

BTW, I am using Synplify with Lattice parts and I have seen it
synthesis badly, then a trivial change to the code makes it work
correctly. Meanwhile it works just fine in simulation. My design is
running with a rather slow clock (12 MHz), so I don't expect it is
timing. The malfunction is not easily explained by a timing error
either, but then maybe I am just not looking hard enough. I was
thinking more of an issue with an unintentional async loop. I have a
number of muxes and there may be an async loop from those.

Rick- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Rickman, your first description is correct. The signal is used as a
one time enable line to an internal component. I’ve a logic analyser
on all the external adrs, data and relevant control strobes to ensure
everything is as it should be. The problem was with one particular
build the signal was not being set when all the external signals were
present and correct. I simply added the test signal to break out the
signal to and external pin and the problem went away, I then removed
the testpoint from the process and the problem did not re-materialise.

Ok, I see. You are using this to disable an internal component that
is only accessed this way on boot. Makes sense.

Like I said, I don't think the synthesis is compiling it incorrectly,
but a bug is always possible. More likely is some obscure bug in your
code that is only manifest under certain conditions.

One thing that I have found is that the synthesis finds different bugs
from simulation. So even if I don't want to simulate a design, I at
least start a simulation because of the additional bug checking. I
would expect that any bug found by simulation that synthesis misses,
is because synthesis works around. But I have seem some strange
behavior get fixed this way.

Rick