Hi-Z Output Bug in Lattice ispLever

R

rickman

Guest
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 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
Click to expand...
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 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.
Click to expand...
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 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
Click to expand...
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 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
Click to expand...
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 :^)
 
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 :^)
Click to expand...
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 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 :^)
Click to expand...
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
Click to expand...
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 pm, rickman <gnu...@gmail.com> wrote:
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 :^)

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- Hide quoted text -

- Show quoted text -
Click to expand...
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 am, Newman <newman5...@yahoo.com> wrote:
On Nov 30, 7:56 pm, rickman <gnu...@gmail.com> wrote:





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

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- 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.- Hide quoted text -

- Show quoted text -
Click to expand...
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:
􀂋 Insert them by default during synthesis.
􀂋 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 “Lattice
Synthesis Header
Libraries” topic in the ispLEVER online Help for details.

http://www.latticesemi.com/lit/docs/manuals/fpga_design_guide.pdf
 
On Nov 30, 6:11 pm, rickman <gnu...@gmail.com> wrote:
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
Click to expand...
Rick,

It is odd, and I completely understand your frustration. To analyze
why this happened, one will need your whole project data-base and I'll
have to ask you to engage your local FAE, if you decide to go this
way...

Also if it is a bug in the SW, then very possibly you won't see it in
a later release (the release 7.2 SP2 you're using is two revs behind,
we have ispLever 8.1 sp1 now and also the new Diamond SW).

The good news is that you can use Lattice free Starter SW to support
the part you're using (all Lattice non-volatile families are fully
covered by the free SW option, you'll need non-free SW only for FPGA
with multi-GB transceivers -SERDES's in Lattice terminology). So I'd
suggest to download the latest ispLever Starter SW and try to use it.

Another thing that I wanted to mention is that you can also try to use
the free version of Lattice new Diamond SW. The point tools are the
same but the GUI is considerably improved (and, of course changed...).
We're getting quite positive feedback from all the customers who tried
the new SW.

Alex

Lattice FAE, writing from home
 
On Dec 1, 2:09 pm, Alex <engin...@gmail.com> wrote:
On Nov 30, 6:11 pm, rickman <gnu...@gmail.com> wrote:



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

Rick,

It is odd, and I completely understand your frustration. To analyze
why this happened, one will need your whole project data-base and I'll
have to ask you to engage your local FAE, if you decide to go this
way...

Also if it is a bug in the SW, then very possibly you won't see it in
a later release  (the release 7.2 SP2 you're using is two revs behind,
we have ispLever 8.1 sp1 now and also the new Diamond SW).

The good news is that you can use Lattice free Starter SW to support
the part you're using (all Lattice non-volatile families are fully
covered by the free SW option, you'll need non-free SW only for FPGA
with multi-GB transceivers -SERDES's in Lattice terminology). So I'd
suggest to download the latest ispLever Starter SW and try to use it.

Another thing that I wanted to mention is that you can also try to use
the free version of Lattice new Diamond SW. The point tools are the
same but the GUI is considerably improved (and, of course changed...).
We're getting quite positive feedback from all the customers who tried
the new SW.
Click to expand...
Hi Alex, Thanks again for the reply. I likely won't pursue this
unless the symptom returns.

I have never really understood what is provided with what versions of
the software. The reason that I paid for a copy two years (or more)
ago was because the simulation was not included with the free
versions. Is that no longer true? Can I simulate my designs with the
starter package now? If so, I guess I don't need to keep my paid for
package and can switch to the free, but up to date tools.

Rick
 
On Dec 1, 1:01 pm, rickman <gnu...@gmail.com> wrote:
On Dec 1, 2:09 pm, Alex <engin...@gmail.com> wrote:



On Nov 30, 6:11 pm, rickman <gnu...@gmail.com> wrote:

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

Rick,

It is odd, and I completely understand your frustration. To analyze
why this happened, one will need your whole project data-base and I'll
have to ask you to engage your local FAE, if you decide to go this
way...

Also if it is a bug in the SW, then very possibly you won't see it in
a later release  (the release 7.2 SP2 you're using is two revs behind,
we have ispLever 8.1 sp1 now and also the new Diamond SW).

The good news is that you can use Lattice free Starter SW to support
the part you're using (all Lattice non-volatile families are fully
covered by the free SW option, you'll need non-free SW only for FPGA
with multi-GB transceivers -SERDES's in Lattice terminology). So I'd
suggest to download the latest ispLever Starter SW and try to use it.

Another thing that I wanted to mention is that you can also try to use
the free version of Lattice new Diamond SW. The point tools are the
same but the GUI is considerably improved (and, of course changed...).
We're getting quite positive feedback from all the customers who tried
the new SW.

Hi Alex, Thanks again for the reply.  I likely won't pursue this
unless the symptom returns.

I have never really understood what is provided with what versions of
the software.  The reason that I paid for a copy two years (or more)
ago was because the simulation was not included with the free
versions.  Is that no longer true?  Can I simulate my designs with the
starter package now?  If so, I guess I don't need to keep my paid for
package and can switch to the free, but up to date tools.

Rick
Click to expand...
Hi Rick,

Lattice Web Edition version of Aldec Active HDL simulator is provided
with free tools. The free simulator has two limitations compared to a
paid-for version of the simulator (Active HDL Lattice Edition):
- the size of the simulated design including the test-bench must be
less than 5000 lines
- only one HDL (user can chose VHDL or Verilog) is supported. Paid-for
version supports both VHDL and Verilog, i.e. full-fledged mix-language
simulation.

For not very big designs not requiring mix-language simulations these
are reasonable constraints. And, of course, one can separately
simulate parts of a design.

Currently Lattice is using a yearly subscription (paid-for) license.
During the year a user will receive all the current updates, upgrades
(and bug fixes) and full SW support.

Let me know if you'll need additional information.

Alex
Lattice FAE, writing from home
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top