Hi-Z Output Bug in Lattice ispLever

I'm not sure what is wrong here. I have a design that I have used in
the past and has worked ok. I am making modifications to it and my Hi-
Z outputs are being grounded. This creates some problems during
operation. The VHDL code is like this...

TMS_B1 <= 'Z';

I just want this output to be Hi-Z for this design so that the pin
output is not driven (which clobbers these signals from other
sources). The lines for this output in the preference file are...

LOCATE COMP "TMS_B1" SITE "36" ;
IOBUF PORT "TMS_B1" IO_TYPE=LVCMOS33 PULLMODE=KEEPER DRIVE=8
SLEWRATE=SLOW ;

When I load the design into the part, the output is always low and
checking the design in Epic, I see the tri-state driver has a 0 on the
input and a 0 on the enable. I believe the 0 on the enable turns on
the output driver because that is how the outputs are configured.

I also looked at the Technology View in Synplify and I find TMS_B1 is
driven by a OB with a 0 on it's input.

Is this a bug or is there something wrong with the way I am doing
this? I made a lot of changes to the overall design before I
discovered this bug so I'm not certain that the preference file lines
have not been changed since this was working, but I don't see how they
can be causing this problem.

Rick

On Nov 29, 11:54=A0pm, rickman <gnu...@gmail.com> wrote:
> I'm not sure what is wrong here. I have a design that I have used in
> the past and has worked ok. I am making modifications to it and my Hi-
> Z outputs are being grounded. This creates some problems during
> operation. The VHDL code is like this...
>
> TMS_B1 <=3D 'Z';
>
> I just want this output to be Hi-Z for this design so that the pin
> output is not driven (which clobbers these signals from other
> sources). The lines for this output in the preference file are...
>
> LOCATE COMP "TMS_B1" SITE "36" ;
> IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8
> SLEWRATE=3DSLOW ;
>
> When I load the design into the part, the output is always low and
> checking the design in Epic, I see the tri-state driver has a 0 on the
> input and a 0 on the enable. I believe the 0 on the enable turns on
> the output driver because that is how the outputs are configured.
>
> I also looked at the Technology View in Synplify and I find TMS_B1 is
> driven by a OB with a 0 on it's input.
>
> Is this a bug or is there something wrong with the way I am doing
> this? I made a lot of changes to the overall design before I
> discovered this bug so I'm not certain that the preference file lines
> have not been changed since this was working, but I don't see how they
> can be causing this problem.
>
> Rick

Rick,
I suppose you have already convinced yourself that it is not the
buskeeper circuit driving the line low.

Bus Maintenance Circuit
Each pad has a weak pull-up, weak pull-down and weak buskeeper
capability. The pull-up and pull-down settings
offer a fixed characteristic, which is useful in creating wired logic
such as wired ORs. However, current can be
slightly higher than other options, depending on the signal state. The
bus-keeper option latches the signal in the
last driven state, holding it at a valid level with minimal power
dissipation. Users can also choose to turn off the bus
maintenance circuitry, minimizing power dissipation and input leakage.
Note that in this case, it is important to
ensure that inputs are driven to a known state to avoid unnecessary
power dissipation in the input buffer.

----------------------------------------------------------------------
Is it possible that the P&R is optimizing the signal out and that
unused I/O are being strapped to '0'?

On Nov 30, 2:35=A0am, Newman <newman5...@yahoo.com> wrote:
> On Nov 29, 11:54=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > I'm not sure what is wrong here. I have a design that I have used in
> > the past and has worked ok. I am making modifications to it and my Hi-
> > Z outputs are being grounded. This creates some problems during
> > operation. The VHDL code is like this...
>
> > TMS_B1 <=3D 'Z';
>
> > I just want this output to be Hi-Z for this design so that the pin
> > output is not driven (which clobbers these signals from other
> > sources). The lines for this output in the preference file are...
>
> > LOCATE COMP "TMS_B1" SITE "36" ;
> > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8
> > SLEWRATE=3DSLOW ;
>
> > When I load the design into the part, the output is always low and
> > checking the design in Epic, I see the tri-state driver has a 0 on the
> > input and a 0 on the enable. I believe the 0 on the enable turns on
> > the output driver because that is how the outputs are configured.
>
> > I also looked at the Technology View in Synplify and I find TMS_B1 is
> > driven by a OB with a 0 on it's input.
>
> > Is this a bug or is there something wrong with the way I am doing
> > this? I made a lot of changes to the overall design before I
> > discovered this bug so I'm not certain that the preference file lines
> > have not been changed since this was working, but I don't see how they
> > can be causing this problem.
>
> > Rick
>
> Rick,
> I suppose you have already convinced yourself that it is not the
> buskeeper circuit driving the line low.
>
> Bus Maintenance Circuit
> Each pad has a weak pull-up, weak pull-down and weak buskeeper
> capability. The pull-up and pull-down settings
> offer a fixed characteristic, which is useful in creating wired logic
> such as wired ORs. However, current can be
> slightly higher than other options, depending on the signal state. The
> bus-keeper option latches the signal in the
> last driven state, holding it at a valid level with minimal power
> dissipation. Users can also choose to turn off the bus
> maintenance circuitry, minimizing power dissipation and input leakage.
> Note that in this case, it is important to
> ensure that inputs are driven to a known state to avoid unnecessary
> power dissipation in the input buffer.

Thanks for the suggestion, but yes, I eliminated that by looking at
the I/O block settings in Epic, the layout editor.  I originally saw
this problem with an LED driving pin.  I set it for hi-z and it was
driving the LED on hard.  A bus keeper wouldn't drive that hard.
Besides, this pin is driving two LEDs, one up and one down.  Hi-z is
the only state where neither LED is on.  When I use logic to select
the three states, 1, 0, Z; then the hi-z state is enabled
appropriately.

I can always work around this by controlling it from some signal such
as reset so that it is always hi-z after the FPGA is up.  It is odd
that this worked just fine before and now screws up.  I haven't
updated any of the development software that I know of, but I haven't
messed with this design since 2008, so there's been a lot of water
under the dam since then.  If it is a tool problem, I may not get an
update.  My maintenance ran out long ago and this is a paid for copy.
I'd hate to have to shell out a kilobuck to get a bug fix so I can
continue using the software that I already paid for.

Rick

On Nov 30, 8:46=A0am, rickman <gnu...@gmail.com> wrote:
> On Nov 30, 2:35=A0am, Newman <newman5...@yahoo.com> wrote:
>
>
>
> > On Nov 29, 11:54=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > I'm not sure what is wrong here. I have a design that I have used in
> > > the past and has worked ok. I am making modifications to it and my Hi=
-
> > > Z outputs are being grounded. This creates some problems during
> > > operation. The VHDL code is like this...
>
> > > TMS_B1 <=3D 'Z';
>
> > > I just want this output to be Hi-Z for this design so that the pin
> > > output is not driven (which clobbers these signals from other
> > > sources). The lines for this output in the preference file are...
>
> > > LOCATE COMP "TMS_B1" SITE "36" ;
> > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8
> > > SLEWRATE=3DSLOW ;
>
> > > When I load the design into the part, the output is always low and
> > > checking the design in Epic, I see the tri-state driver has a 0 on th=
e
> > > input and a 0 on the enable. I believe the 0 on the enable turns on
> > > the output driver because that is how the outputs are configured.
>
> > > I also looked at the Technology View in Synplify and I find TMS_B1 is
> > > driven by a OB with a 0 on it's input.
>
> > > Is this a bug or is there something wrong with the way I am doing
> > > this? I made a lot of changes to the overall design before I
> > > discovered this bug so I'm not certain that the preference file lines
> > > have not been changed since this was working, but I don't see how the=
y
> > > can be causing this problem.
>
> > > Rick
>
> > Rick,
> > I suppose you have already convinced yourself that it is not the
> > buskeeper circuit driving the line low.
>
> > Bus Maintenance Circuit
> > Each pad has a weak pull-up, weak pull-down and weak buskeeper
> > capability. The pull-up and pull-down settings
> > offer a fixed characteristic, which is useful in creating wired logic
> > such as wired ORs. However, current can be
> > slightly higher than other options, depending on the signal state. The
> > bus-keeper option latches the signal in the
> > last driven state, holding it at a valid level with minimal power
> > dissipation. Users can also choose to turn off the bus
> > maintenance circuitry, minimizing power dissipation and input leakage.
> > Note that in this case, it is important to
> > ensure that inputs are driven to a known state to avoid unnecessary
> > power dissipation in the input buffer.
>
> Thanks for the suggestion, but yes, I eliminated that by looking at
> the I/O block settings in Epic, the layout editor. =A0I originally saw
> this problem with an LED driving pin. =A0I set it for hi-z and it was
> driving the LED on hard. =A0A bus keeper wouldn't drive that hard.
> Besides, this pin is driving two LEDs, one up and one down. =A0Hi-z is
> the only state where neither LED is on. =A0When I use logic to select
> the three states, 1, 0, Z; then the hi-z state is enabled
> appropriately.
>
> I can always work around this by controlling it from some signal such
> as reset so that it is always hi-z after the FPGA is up. =A0It is odd
> that this worked just fine before and now screws up. =A0I haven't
> updated any of the development software that I know of, but I haven't
> messed with this design since 2008, so there's been a lot of water
> under the dam since then. =A0If it is a tool problem, I may not get an
> update. =A0My maintenance ran out long ago and this is a paid for copy.
> I'd hate to have to shell out a kilobuck to get a bug fix so I can
> continue using the software that I already paid for.
>
> Rick

This looks remarkably like something I remember from older Xilinx
projects where assigning an output to 'Z' effectively removed it from
the
design.  (the output isn't "driven" so get rid of it)  Then the
default
action for the backend tools is to take any undriven outputs and
ground them (you must have forgotten to assign a value to this).

What would happen if you changed the output so it is only tristate
under some condition?  You could pick some condition that you
know is always true, but the synthesizer can't guess, or make the
output briefly drive (high or low) as the design comes out of reset.

Does your project perhaps have a setting or unused IOB's to
be "virtual grounds"?

All I can think of...

-- Gabor

On Nov 29, 9:54=A0pm, rickman <gnu...@gmail.com> wrote:
> I'm not sure what is wrong here. I have a design that I have used in
> the past and has worked ok. I am making modifications to it and my Hi-
> Z outputs are being grounded. This creates some problems during
> operation. The VHDL code is like this...
>
> TMS_B1 <=3D 'Z';
>
> I just want this output to be Hi-Z for this design so that the pin
> output is not driven (which clobbers these signals from other
> sources). The lines for this output in the preference file are...
>
> LOCATE COMP "TMS_B1" SITE "36" ;
> IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8
> SLEWRATE=3DSLOW ;
>
> When I load the design into the part, the output is always low and
> checking the design in Epic, I see the tri-state driver has a 0 on the
> input and a 0 on the enable. I believe the 0 on the enable turns on
> the output driver because that is how the outputs are configured.
>
> I also looked at the Technology View in Synplify and I find TMS_B1 is
> driven by a OB with a 0 on it's input.
>
> Is this a bug or is there something wrong with the way I am doing
> this? I made a lot of changes to the overall design before I
> discovered this bug so I'm not certain that the preference file lines
> have not been changed since this was working, but I don't see how they
> can be causing this problem.
>
> Rick

Rick,

Two suggestions:
- try to use the syn_keep attribute in Synplify for the TMS_B1 net
- remove the keeper option in the constraint (set PULLMODE =3D NONE,
just for verification purposes)

If nothing will change, could you let me know the SW version and the
device you're using?

Alex

Lattice FAE
(writing from home; just trying to help out :^)

On Nov 30, 2:22 pm, Alex <engin...@gmail.com> wrote:
> On Nov 29, 9:54 pm, rickman <gnu...@gmail.com> wrote:
>
> > I'm not sure what is wrong here. I have a design that I have used in
> > the past and has worked ok. I am making modifications to it and my Hi-
> > Z outputs are being grounded. This creates some problems during
> > operation. The VHDL code is like this...
>
> > TMS_B1 <= 'Z';
>
> > I just want this output to be Hi-Z for this design so that the pin
> > output is not driven (which clobbers these signals from other
> > sources). The lines for this output in the preference file are...
>
> > LOCATE COMP "TMS_B1" SITE "36" ;
> > IOBUF PORT "TMS_B1" IO_TYPE=LVCMOS33 PULLMODE=KEEPER DRIVE=8
> > SLEWRATE=SLOW ;
>
> > When I load the design into the part, the output is always low and
> > checking the design in Epic, I see the tri-state driver has a 0 on the
> > input and a 0 on the enable. I believe the 0 on the enable turns on
> > the output driver because that is how the outputs are configured.
>
> > I also looked at the Technology View in Synplify and I find TMS_B1 is
> > driven by a OB with a 0 on it's input.
>
> > Is this a bug or is there something wrong with the way I am doing
> > this? I made a lot of changes to the overall design before I
> > discovered this bug so I'm not certain that the preference file lines
> > have not been changed since this was working, but I don't see how they
> > can be causing this problem.
>
> > Rick
>
> Rick,
>
> Two suggestions:
> - try to use the syn_keep attribute in Synplify for the TMS_B1 net
> - remove the keeper option in the constraint (set PULLMODE = NONE,
> just for verification purposes)
>
> If nothing will change, could you let me know the SW version and the
> device you're using?
>
> Alex
>
> Lattice FAE
> (writing from home; just trying to help out :^)

Hi Alex, thanks for the response.  I haven't bothered my local FAE
with this yet.  I thought I'd give the other channels a shot first.

FYI, I posted this to the Lattice forums under ispLever/Synplify.  I
posted a second time with the additional info that you are now asking
for.  I already tried the PULLMODE=NONE with another signal driving an
LED and that didn't work.  I haven't tried the syn_keep attribute
since it is not removing the signal really.  It is just treating it
the wrong way.  There are other pins which are not assigned at all and
they get the same connection to '0'.  Unused inputs have no
configuration in Epic.  I was once told, IIRC, that the default action
for outputs not assigned is to ground them so they can be used as
additional ground connections.  But I'm not even sure that was Lattice
software, it may have been Altera.  I have no idea if this is relevant
or not.

I tried the syn_keep attribute on the output signal, TMS_B1 and got a
warning:
@W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS-
DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of
proper type in current declarative region

I think it is telling me this attribute does not apply to outputs!

My second post in the forums with the software info is below.  I am
still not clear on exactly what I can get in the way of updates to the
software.  This is a paid for copy of ispLever, not the starter
version.  But I never renewed the maintenance.  I can get a license
renewal each year when the license file runs out, but I don't know if
that just lets me keep using the software or if I can get any bug
fixes... such as this.  I know the tools compiled this code correctly
at one time.  I would have never been able to program my boards on the
test fixture if it didn't work.  I just need to figure out if I broke
it or an update that I last obtained did something bad.  I find it
hard to believe that something so fundamental was broken in a software
update...

Just to mention this again, looking at the technology view in
Synplify, it clearly shows an output block (OB) with a '0' on the
input and the output driving TMS_B1.  So I guess this is really a
Synplify issue, no?

Rick


*****************************************************
I see I failed to give any details of the software I am using. Also, I
read the tool output carefully and found that it tells me it is tying
the enable of the tri-state driver to ground. I'm actually seeing this
on all six high impedance outputs I need.

@W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms-
dcard_test_fpga.vhd":294:12:294:14|tristate driver TMS_B2_1 on net
TMS_B2_1 has its enable tied to GND (module MS_Test)

The target chip is LXFP3C-3T100C

ispLEVER Service Pack SP7.2.02.21.23.09 Date: 6-23-2009 Time: 13:16:02
ispLEVER Service Pack SP7.2.01.18.08.09 Date: 4-9-2009 Time: 10:23:05
ispLEVER Production Build 7.2.00.41.49.08 Date: 4-8-2009 Time:
23:50:54

Synplify Pro for Lattice 9.6L1, Build 069R, Built Nov 3 2008
Synplicity VHDL Compiler, version 1.0, Build 020R, built Nov 5 2008
Synplicity Lattice ORCA FPGA Technology Mapper, Version 9.4.2, Build
061R, Built Nov 25 2008
Synplicity Lattice FPGA Technology Mapper, Version 9.4.2, Build 054R,
Built Nov 14 2008 10:11:08

On Nov 30, 2:22=A0pm, Alex <engin...@gmail.com> wrote:
> On Nov 29, 9:54=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > I'm not sure what is wrong here. I have a design that I have used in
> > the past and has worked ok. I am making modifications to it and my Hi-
> > Z outputs are being grounded. This creates some problems during
> > operation. The VHDL code is like this...
>
> > TMS_B1 <=3D 'Z';
>
> > I just want this output to be Hi-Z for this design so that the pin
> > output is not driven (which clobbers these signals from other
> > sources). The lines for this output in the preference file are...
>
> > LOCATE COMP "TMS_B1" SITE "36" ;
> > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8
> > SLEWRATE=3DSLOW ;
>
> > When I load the design into the part, the output is always low and
> > checking the design in Epic, I see the tri-state driver has a 0 on the
> > input and a 0 on the enable. I believe the 0 on the enable turns on
> > the output driver because that is how the outputs are configured.
>
> > I also looked at the Technology View in Synplify and I find TMS_B1 is
> > driven by a OB with a 0 on it's input.
>
> > Is this a bug or is there something wrong with the way I am doing
> > this? I made a lot of changes to the overall design before I
> > discovered this bug so I'm not certain that the preference file lines
> > have not been changed since this was working, but I don't see how they
> > can be causing this problem.
>
> > Rick
>
> Rick,
>
> Two suggestions:
> - try to use the syn_keep attribute in Synplify for the TMS_B1 net
> - remove the keeper option in the constraint (set PULLMODE =3D NONE,
> just for verification purposes)
>
> If nothing will change, could you let me know the SW version and the
> device you're using?
>
> Alex
>
> Lattice FAE
> (writing from home; just trying to help out :^)

I'm not sure what to make of this.  I tried looking at the results
again with syn_keep applied and it *did* affect the output.  But now
it uses a Hi-Z output WITHOUT the syn_keep attribute!!!  I changed
nothing else.  I did not change the KEEPER setting in the lpf file.

I hate when things don't work, but I hate worse when they start
working and I don't know why!  Clearly I can't say I was doing
everything correctly, but I have no idea what changed either.  The
strange part is I still get warnings from Synplicity about tying the
TMS_B1 output enable to ground!

@W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms-
dcard_test_fpga.vhd":295:12:295:14|tristate driver TMS_B1_1 on net
TMS_B1_1 has its enable tied to GND (module MS_Test)

as well as

@W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms-
dcard_test_fpga.vhd":42:1:42:6|tristate driver TMS_B1_obuft.un1[0] on
net TMS_B1 has its enable tied to GND (module MS_Test)

in addition to

@W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS-
DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of
proper type in current declarative region

I haven't a clue about this.  Worse, every time I generate a new bit
file, I'll have to check the design in Epic to make sure these outputs
are truly tri-stated.  :-(

Rick

On Nov 30, 9:58 am, Gabor <ga...@alacron.com> wrote:
> On Nov 30, 8:46 am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Nov 30, 2:35 am, Newman <newman5...@yahoo.com> wrote:
>
> > > On Nov 29, 11:54 pm, rickman <gnu...@gmail.com> wrote:
>
> > > > I'm not sure what is wrong here. I have a design that I have used in
> > > > the past and has worked ok. I am making modifications to it and my Hi-
> > > > Z outputs are being grounded. This creates some problems during
> > > > operation. The VHDL code is like this...
>
> > > > TMS_B1 <= 'Z';
>
> > > > I just want this output to be Hi-Z for this design so that the pin
> > > > output is not driven (which clobbers these signals from other
> > > > sources). The lines for this output in the preference file are...
>
> > > > LOCATE COMP "TMS_B1" SITE "36" ;
> > > > IOBUF PORT "TMS_B1" IO_TYPE=LVCMOS33 PULLMODE=KEEPER DRIVE=8
> > > > SLEWRATE=SLOW ;
>
> > > > When I load the design into the part, the output is always low and
> > > > checking the design in Epic, I see the tri-state driver has a 0 on the
> > > > input and a 0 on the enable. I believe the 0 on the enable turns on
> > > > the output driver because that is how the outputs are configured.
>
> > > > I also looked at the Technology View in Synplify and I find TMS_B1 is
> > > > driven by a OB with a 0 on it's input.
>
> > > > Is this a bug or is there something wrong with the way I am doing
> > > > this? I made a lot of changes to the overall design before I
> > > > discovered this bug so I'm not certain that the preference file lines
> > > > have not been changed since this was working, but I don't see how they
> > > > can be causing this problem.
>
> > > > Rick
>
> > > Rick,
> > > I suppose you have already convinced yourself that it is not the
> > > buskeeper circuit driving the line low.
>
> > > Bus Maintenance Circuit
> > > Each pad has a weak pull-up, weak pull-down and weak buskeeper
> > > capability. The pull-up and pull-down settings
> > > offer a fixed characteristic, which is useful in creating wired logic
> > > such as wired ORs. However, current can be
> > > slightly higher than other options, depending on the signal state. The
> > > bus-keeper option latches the signal in the
> > > last driven state, holding it at a valid level with minimal power
> > > dissipation. Users can also choose to turn off the bus
> > > maintenance circuitry, minimizing power dissipation and input leakage.
> > > Note that in this case, it is important to
> > > ensure that inputs are driven to a known state to avoid unnecessary
> > > power dissipation in the input buffer.
>
> > Thanks for the suggestion, but yes, I eliminated that by looking at
> > the I/O block settings in Epic, the layout editor.  I originally saw
> > this problem with an LED driving pin.  I set it for hi-z and it was
> > driving the LED on hard.  A bus keeper wouldn't drive that hard.
> > Besides, this pin is driving two LEDs, one up and one down.  Hi-z is
> > the only state where neither LED is on.  When I use logic to select
> > the three states, 1, 0, Z; then the hi-z state is enabled
> > appropriately.
>
> > I can always work around this by controlling it from some signal such
> > as reset so that it is always hi-z after the FPGA is up.  It is odd
> > that this worked just fine before and now screws up.  I haven't
> > updated any of the development software that I know of, but I haven't
> > messed with this design since 2008, so there's been a lot of water
> > under the dam since then.  If it is a tool problem, I may not get an
> > update.  My maintenance ran out long ago and this is a paid for copy.
> > I'd hate to have to shell out a kilobuck to get a bug fix so I can
> > continue using the software that I already paid for.
>
> > Rick
>
> This looks remarkably like something I remember from older Xilinx
> projects where assigning an output to 'Z' effectively removed it from
> the
> design.  (the output isn't "driven" so get rid of it)  Then the
> default
> action for the backend tools is to take any undriven outputs and
> ground them (you must have forgotten to assign a value to this).
>
> What would happen if you changed the output so it is only tristate
> under some condition?  You could pick some condition that you
> know is always true, but the synthesizer can't guess, or make the
> output briefly drive (high or low) as the design comes out of reset.
>
> Does your project perhaps have a setting or unused IOB's to
> be "virtual grounds"?
>
> All I can think of...
>
> -- Gabor

Hi Gabor.  I also have outputs driving pairs of LEDs that are
conditional and can be either '0', '1' or 'Z'.  They work just fine.
In fact, I first saw this on LED drive outputs that I drove with a
'Z'.  The red LEDs came on which means it was pulled hard to ground.
I turned off the buskeeper mode and it still drove the output hard to
ground.  That was when I first looked at the design in Epic and saw
the tri-state control driven to a fixed '0' instead of a fixed '1',
like it is now!  If I hadn't see this before, it would have been ten
times harder to figure out what was keeping my programming cable from
working with by target boards!  These JTAG signals are also connected
to the test fixture FPGA in case I get to the point where I want the
FPGA to program the target boards instead of using the Lattice
software.  Oddly enough, Lattice cautions you against using the USB
cable for production programming.  I guess this is just a CYA thing in
case it doesn't work correctly and you ship 10,000 boards that aren't
programmed right... "don't come back to us"!

I had considered controlling the tri-states with some signal that
would not conflict with an external driver of the JTAG signals, such
as the GSR or maybe a switch input.  But the issue seems to have
resolved itself.  I'm not sure I will ever know what was wrong unless
it returns.  I know the preference file gets rewritten each time I run
the tool, but I can't say the file actually changes.  I haven no idea
why it has to write the file back out each time.  The only thing it
seems to change is when I put a title block at the head of the file,
the tools keep writing the line, "COMMERCIAL;" just in front of it.
No matter where I put this line in the file, it gets moved to the
first line.

If nothing else, it helps to have others make suggestions.  It can be
easier to figure things out when you have to explain something and
think about other's comments.  Thanks.

Rick

On Nov 30, 7:56=A0pm, rickman <gnu...@gmail.com> wrote:
> On Nov 30, 2:22=A0pm, Alex <engin...@gmail.com> wrote:
>
>
>
>
>
> > On Nov 29, 9:54=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > I'm not sure what is wrong here. I have a design that I have used in
> > > the past and has worked ok. I am making modifications to it and my Hi=
-
> > > Z outputs are being grounded. This creates some problems during
> > > operation. The VHDL code is like this...
>
> > > TMS_B1 <=3D 'Z';
>
> > > I just want this output to be Hi-Z for this design so that the pin
> > > output is not driven (which clobbers these signals from other
> > > sources). The lines for this output in the preference file are...
>
> > > LOCATE COMP "TMS_B1" SITE "36" ;
> > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8
> > > SLEWRATE=3DSLOW ;
>
> > > When I load the design into the part, the output is always low and
> > > checking the design in Epic, I see the tri-state driver has a 0 on th=
e
> > > input and a 0 on the enable. I believe the 0 on the enable turns on
> > > the output driver because that is how the outputs are configured.
>
> > > I also looked at the Technology View in Synplify and I find TMS_B1 is
> > > driven by a OB with a 0 on it's input.
>
> > > Is this a bug or is there something wrong with the way I am doing
> > > this? I made a lot of changes to the overall design before I
> > > discovered this bug so I'm not certain that the preference file lines
> > > have not been changed since this was working, but I don't see how the=
y
> > > can be causing this problem.
>
> > > Rick
>
> > Rick,
>
> > Two suggestions:
> > - try to use the syn_keep attribute in Synplify for the TMS_B1 net
> > - remove the keeper option in the constraint (set PULLMODE =3D NONE,
> > just for verification purposes)
>
> > If nothing will change, could you let me know the SW version and the
> > device you're using?
>
> > Alex
>
> > Lattice FAE
> > (writing from home; just trying to help out :^)
>
> I'm not sure what to make of this. =A0I tried looking at the results
> again with syn_keep applied and it *did* affect the output. =A0But now
> it uses a Hi-Z output WITHOUT the syn_keep attribute!!! =A0I changed
> nothing else. =A0I did not change the KEEPER setting in the lpf file.
>
> I hate when things don't work, but I hate worse when they start
> working and I don't know why! =A0Clearly I can't say I was doing
> everything correctly, but I have no idea what changed either. =A0The
> strange part is I still get warnings from Synplicity about tying the
> TMS_B1 output enable to ground!
>
> @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms-
> dcard_test_fpga.vhd":295:12:295:14|tristate driver TMS_B1_1 on net
> TMS_B1_1 has its enable tied to GND (module MS_Test)
>
> as well as
>
> @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms-
> dcard_test_fpga.vhd":42:1:42:6|tristate driver TMS_B1_obuft.un1[0] on
> net TMS_B1 has its enable tied to GND (module MS_Test)
>
> in addition to
>
> @W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS-
> DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of
> proper type in current declarative region
>
> I haven't a clue about this. =A0Worse, every time I generate a new bit
> file, I'll have to check the design in Epic to make sure these outputs
> are truly tri-stated. =A0:-(
>
> Rick- Hide quoted text -
>
> - Show quoted text -

If one can instantiate IOB primitives like you can do in Xilinx, one
thing to try would be to instantiate the hi Z IOB's and manually strap
the tristate enable in the code.  This would seem to take the
Synthesizer out of the picture.

Several years ago, I had a bizarre problem with a Xilinx installation
where the IT department forced me to use a network drive that was
located in another state.  I think the cache was not maintaining sync
or something. The cause and effect relationship observed by me
disappeared during that period.  I started using only local design
data on my machine and things got much better.

On Dec 1, 1:08=C2=A0am, Newman <newman5...@yahoo.com> wrote:
> On Nov 30, 7:56=C2=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
>
>
> > On Nov 30, 2:22=C2=A0pm, Alex <engin...@gmail.com> wrote:
>
> > > On Nov 29, 9:54=C2=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > > I'm not sure what is wrong here. I have a design that I have used i=
n
> > > > the past and has worked ok. I am making modifications to it and my =
Hi-
> > > > Z outputs are being grounded. This creates some problems during
> > > > operation. The VHDL code is like this...
>
> > > > TMS_B1 <=3D 'Z';
>
> > > > I just want this output to be Hi-Z for this design so that the pin
> > > > output is not driven (which clobbers these signals from other
> > > > sources). The lines for this output in the preference file are...
>
> > > > LOCATE COMP "TMS_B1" SITE "36" ;
> > > > IOBUF PORT "TMS_B1" IO_TYPE=3DLVCMOS33 PULLMODE=3DKEEPER DRIVE=3D8
> > > > SLEWRATE=3DSLOW ;
>
> > > > When I load the design into the part, the output is always low and
> > > > checking the design in Epic, I see the tri-state driver has a 0 on =
the
> > > > input and a 0 on the enable. I believe the 0 on the enable turns on
> > > > the output driver because that is how the outputs are configured.
>
> > > > I also looked at the Technology View in Synplify and I find TMS_B1 =
is
> > > > driven by a OB with a 0 on it's input.
>
> > > > Is this a bug or is there something wrong with the way I am doing
> > > > this? I made a lot of changes to the overall design before I
> > > > discovered this bug so I'm not certain that the preference file lin=
es
> > > > have not been changed since this was working, but I don't see how t=
hey
> > > > can be causing this problem.
>
> > > > Rick
>
> > > Rick,
>
> > > Two suggestions:
> > > - try to use the syn_keep attribute in Synplify for the TMS_B1 net
> > > - remove the keeper option in the constraint (set PULLMODE =3D NONE,
> > > just for verification purposes)
>
> > > If nothing will change, could you let me know the SW version and the
> > > device you're using?
>
> > > Alex
>
> > > Lattice FAE
> > > (writing from home; just trying to help out :^)
>
> > I'm not sure what to make of this. =C2=A0I tried looking at the results
> > again with syn_keep applied and it *did* affect the output. =C2=A0But n=
ow
> > it uses a Hi-Z output WITHOUT the syn_keep attribute!!! =C2=A0I changed
> > nothing else. =C2=A0I did not change the KEEPER setting in the lpf file=
.
>
> > I hate when things don't work, but I hate worse when they start
> > working and I don't know why! =C2=A0Clearly I can't say I was doing
> > everything correctly, but I have no idea what changed either. =C2=A0The
> > strange part is I still get warnings from Synplicity about tying the
> > TMS_B1 output enable to ground!
>
> > @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms-
> > dcard_test_fpga.vhd":295:12:295:14|tristate driver TMS_B1_1 on net
> > TMS_B1_1 has its enable tied to GND (module MS_Test)
>
> > as well as
>
> > @W: MO111 :"c:\arius\boards\irig-b-testbed\fpga\ms-
> > dcard_test_fpga.vhd":42:1:42:6|tristate driver TMS_B1_obuft.un1[0] on
> > net TMS_B1 has its enable tied to GND (module MS_Test)
>
> > in addition to
>
> > @W: CD134 :"C:\arius\boards\irig-b-testbed\fpga\MS-
> > DCARD_Test_FPGA.vhd":289:24:289:29|No such identifier, tms_b1, of
> > proper type in current declarative region
>
> > I haven't a clue about this. =C2=A0Worse, every time I generate a new b=
it
> > file, I'll have to check the design in Epic to make sure these outputs
> > are truly tri-stated. =C2=A0:-(
>
> > Rick- Hide quoted text -
>
> > - Show quoted text -
>
> If one can instantiate IOB primitives like you can do in Xilinx, one
> thing to try would be to instantiate the hi Z IOB's and manually strap
> the tristate enable in the code. =C2=A0This would seem to take the
> Synthesizer out of the picture.
>
> Several years ago, I had a bizarre problem with a Xilinx installation
> where the IT department forced me to use a network drive that was
> located in another state. =C2=A0I think the cache was not maintaining syn=
c
> or something. The cause and effect relationship observed by me
> disappeared during that period. =C2=A0I started using only local design
> data on my machine and things got much better.- Hide quoted text -
>
> - Show quoted text -

Sounds like a hassle -  (automatic I/O insertion by synthesis must be
disabled).


I/O Buffer Insertion
You can use two ways to insert I/O buffers or pads into the EDIF
netlist
produced by logic synthesis:
=F4=80=82=8B Insert them by default during synthesis.
=F4=80=82=8B Instantiate I/O buffers (automatic I/O insertion by synthesis =
must
be
disabled).
To minimize the amount of code required to design with I/O buffers,
Lattice
Semiconductor provides a Verilog HDL and a VHDL synthesis header
library
file for each major FPGA device family. Refer to the =E2=80=9CLattice
Synthesis Header
Libraries=E2=80=9D topic in the ispLEVER online Help for details.

http://www.latticesemi.com/lit/docs/manuals/fpga_design_guide.pdf