Coolrunner II: what's wrong up here ?

Hi all,

I have a problem with Coolrunner II pld (http://www.xilinx.com/
products/devkits/SK-CRII-L-G.htm).
I have written a program similar to the project counter given in the
Xilinx handbook example.
Full code is available on http://webs.hogent.be/~a00027gd/teller.txt
In ISE the code compiles correctly except for one warning message.
The handbook example gives the same error message so this cannot be
the problem.  I used PACE to assign pins and created the .jed-file as
usual

Programming the device with this .jed results in a dead board ?
If I program with the .jed from the handbook example it runs fine ?

I spend a couple of days on it and cannot find anything wrong.   Could
the problem be board specific (eg timing constraints, ...) or anything
else

In fact the basic question is: how can I bring the dead board to life
with this code ?

Thanks a lot for help

Gert

"gert1999" <ggddbb@gmail.com> wrote in message 
news:88ff57c2-b9e8-4a34-8e56-6a7afd698641@e20g2000vbc.googlegroups.com...
> Hi all,
>
> I have a problem with Coolrunner II pld (http://www.xilinx.com/
> products/devkits/SK-CRII-L-G.htm).
> I have written a program similar to the project counter given in the
> Xilinx handbook example.
> Full code is available on http://webs.hogent.be/~a00027gd/teller.txt
> In ISE the code compiles correctly except for one warning message.
> The handbook example gives the same error message so this cannot be
> the problem.  I used PACE to assign pins and created the .jed-file as
> usual

I didn't look in any detail. How does it look in simulation? Is it counting? 
If it is, check the UCF for pin assignments, pull-up/-down attributes. Look 
especially at the reset line. If it doesn't count in simulation, check the 
reset sense, 1 or 0. Check the clock. ... ... ...

"MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
news:NqkPl.26630$c45.6895@nlpi065.nbdc.sbc.com...
> "gert1999" <ggddbb@gmail.com> wrote in message 
> news:88ff57c2-b9e8-4a34-8e56-6a7afd698641@e20g2000vbc.googlegroups.com...
>> Hi all,
>>
>> I have a problem with Coolrunner II pld (http://www.xilinx.com/
>> products/devkits/SK-CRII-L-G.htm).
>> I have written a program similar to the project counter given in the
>> Xilinx handbook example.
>> Full code is available on http://webs.hogent.be/~a00027gd/teller.txt
>> In ISE the code compiles correctly except for one warning message.
>> The handbook example gives the same error message so this cannot be
>> the problem.  I used PACE to assign pins and created the .jed-file as
>> usual
>
> I didn't look in any detail. How does it look in simulation? Is it 
> counting? If it is, check the UCF for pin assignments, pull-up/-down 
> attributes. Look especially at the reset line. If it doesn't count in 
> simulation, check the reset sense, 1 or 0. Check the clock. ... ... ...

[PS] Check the digit select, common cathode or anode on the 7-segment. Is it 
driven correctly? I didn't see that in the ports.

On 15 mei, 22:48, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "MikeWhy" <boat042-nos...@yahoo.com> wrote in message
>
> news:NqkPl.26630$c45.6895@nlpi065.nbdc.sbc.com...
>
>
>

> > "gert1999" <ggd...@gmail.com> wrote in message
> >news:88ff57c2-b9e8-4a34-8e56-6a7afd698641@e20g2000vbc.googlegroups.com..=
.
> >> Hi all,
>
> >> I have a problem with Coolrunner II pld (http://www.xilinx.com/
> >> products/devkits/SK-CRII-L-G.htm).
> >> I have written a program similar to the project counter given in the
> >> Xilinx handbook example.
> >> Full code is available onhttp://webs.hogent.be/~a00027gd/teller.txt
> >> In ISE the code compiles correctly except for one warning message.
> >> The handbook example gives the same error message so this cannot be
> >> the problem. =A0I used PACE to assign pins and created the .jed-file a=
s
> >> usual
>
> > I didn't look in any detail. How does it look in simulation? Is it
> > counting? If it is, check the UCF for pin assignments, pull-up/-down
> > attributes. Look especially at the reset line. If it doesn't count in
> > simulation, check the reset sense, 1 or 0. Check the clock. ... ... ...
>
> [PS] Check the digit select, common cathode or anode on the 7-segment. Is=
 it
> driven correctly? I didn't see that in the ports.

Hello

Thanks for helping: you gave some usefull tips, however the board is
still dead :-(

I've added some files on the same link
First you got the reset line correct: it should be driven low instead
of high (if reset=3D'0')
Second I added the common driving kathode pins.   In the manual they
indicate they should all be driven low if not multiplexing.  I've done
so, this could also be derived from the schematic as the are pnp
transistors.  However I can't find any code in the handbook example:
how do they drive them low if there is no code written ?  Setting
attributes might be the key ??
.
A new version of the source is the file teller_update1.txt
I placed screenshots of pinmapping, low level simulation of the
counter, and top level simulation of the whole design

As one can see: the counter counts, but the LEDs are not being
driven ?? They just stay low resulting in a dead board
What exactly do you mean by pull down atributes ?  I only specified
clock_ext DATA_GATE as they did so in the manual

Hope we can bring the board to life ...

Thanks

Gert

"gert1999" <ggddbb@gmail.com> wrote in message 
news:95580829-2b4b-4981-acb5-9489958899bd@v4g2000vba.googlegroups.com...
I've added some files on the same link
First you got the reset line correct: it should be driven low instead
of high (if reset='0')
Second I added the common driving kathode pins.   In the manual they
indicate they should all be driven low if not multiplexing.  I've done
so, this could also be derived from the schematic as the are pnp
transistors.  However I can't find any code in the handbook example:
how do they drive them low if there is no code written ?  Setting
attributes might be the key ??
.
A new version of the source is the file teller_update1.txt
I placed screenshots of pinmapping, low level simulation of the
counter, and top level simulation of the whole design

As one can see: the counter counts, but the LEDs are not being
driven ?? They just stay low resulting in a dead board
What exactly do you mean by pull down atributes ?  I only specified
clock_ext DATA_GATE as they did so in the manual

========
You're now looking in the right places, and asking the right questions. The 
next step is to answer them yourself. ;)

Pullup and pulldown apply more to reading switches; don't let me confuse you 
with my confusion. Data-gate is related to power save modes. Try disabling 
it removing the attribute, or make sure its driven correctly. Try driving a 
constant '0' on the common cathode. Failing that, physically tie it to 
ground on the board. Try probing with a meter and look for voltages you 
would expect. The LED pins should read somewhat less than half the high 
state voltage. Check that the display cathode is grounded, not just 
floating. Check that the data-gate pin reads whatever means not power save.

Good luck.

On 16 mei, 19:08, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "gert1999" <ggd...@gmail.com> wrote in message
>
> news:95580829-2b4b-4981-acb5-9489958899bd@v4g2000vba.googlegroups.com...
> I've added some files on the same link
> First you got the reset line correct: it should be driven low instead
> of high (if reset=3D'0')
> Second I added the common driving kathode pins. =A0 In the manual they
> indicate they should all be driven low if not multiplexing. =A0I've done
> so, this could also be derived from the schematic as the are pnp
> transistors. =A0However I can't find any code in the handbook example:
> how do they drive them low if there is no code written ? =A0Setting
> attributes might be the key ??
> .
> A new version of the source is the file teller_update1.txt
> I placed screenshots of pinmapping, low level simulation of the
> counter, and top level simulation of the whole design
>
> As one can see: the counter counts, but the LEDs are not being
> driven ?? They just stay low resulting in a dead board
> What exactly do you mean by pull down atributes ? =A0I only specified
> clock_ext DATA_GATE as they did so in the manual
>
> =3D=3D=3D=3D=3D=3D=3D=3D
> You're now looking in the right places, and asking the right questions. T=
he
> next step is to answer them yourself. ;)
>
> Pullup and pulldown apply more to reading switches; don't let me confuse =
you
> with my confusion. Data-gate is related to power save modes. Try disablin=
g
> it removing the attribute, or make sure its driven correctly. Try driving=
 a
> constant '0' on the common cathode. Failing that, physically tie it to
> ground on the board. Try probing with a meter and look for voltages you
> would expect. The LED pins should read somewhat less than half the high
> state voltage. Check that the display cathode is grounded, not just
> floating. Check that the data-gate pin reads whatever means not power sav=
e.
>
> Good luck.

=3D=3D=3D=3D
Thank's a lot for helping.   I know about pullup and pulldown in
simpel logic (active / passive pull up and that kind of things)
I have been trying to answer the questions for several days and
decided to ask help :-)

I'll see what to do with it
There are so many questions and Xilinx manuals are not very helpfull
(they make it look so simple ..  )

If it ever works I wil leave a mesage here (if the article will still
be avaiilable in the newsgroup :-) )

Thanks again

Gert

"gert1999" <ggddbb@gmail.com> wrote in message 
news:af6b611f-0775-41ad-a664-ab6605364e88@o14g2000vbo.googlegroups.com...
On 16 mei, 19:08, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "gert1999" <ggd...@gmail.com> wrote in message
>
> news:95580829-2b4b-4981-acb5-9489958899bd@v4g2000vba.googlegroups.com...
> I've added some files on the same link
> First you got the reset line correct: it should be driven low instead
> of high (if reset='0')
> Second I added the common driving kathode pins. In the manual they
> indicate they should all be driven low if not multiplexing. I've done
> so, this could also be derived from the schematic as the are pnp
> transistors. However I can't find any code in the handbook example:
> how do they drive them low if there is no code written ? Setting
> attributes might be the key ??
> .
> A new version of the source is the file teller_update1.txt
> I placed screenshots of pinmapping, low level simulation of the
> counter, and top level simulation of the whole design
>
> As one can see: the counter counts, but the LEDs are not being
> driven ?? They just stay low resulting in a dead board
> What exactly do you mean by pull down atributes ? I only specified
> clock_ext DATA_GATE as they did so in the manual
>
> ========
> You're now looking in the right places, and asking the right questions. 
> The
> next step is to answer them yourself. ;)
>
> Pullup and pulldown apply more to reading switches; don't let me confuse 
> you
> with my confusion. Data-gate is related to power save modes. Try disabling
> it removing the attribute, or make sure its driven correctly. Try driving 
> a
> constant '0' on the common cathode. Failing that, physically tie it to
> ground on the board. Try probing with a meter and look for voltages you
> would expect. The LED pins should read somewhat less than half the high
> state voltage. Check that the display cathode is grounded, not just
> floating. Check that the data-gate pin reads whatever means not power 
> save.
>
> Good luck.

====
Thank's a lot for helping.   I know about pullup and pulldown in
simpel logic (active / passive pull up and that kind of things)
I have been trying to answer the questions for several days and
decided to ask help :-)

I'll see what to do with it
There are so many questions and Xilinx manuals are not very helpfull
(they make it look so simple ..  )

If it ever works I wil leave a mesage here (if the article will still
be avaiilable in the newsgroup :-) )

=======
Double check that reset pin. The testbench likely just needed a simple 
stimulus to take it out of reset, something like rst <= '0', while the code 
was actually fine. Read the schematic and be sure you have the right 
pullup/down sense on that pin. Same with data-gate. Probe the logic levels 
with a meter. If you have an I/O header available, route the signals to the 
header to make probing easier and somewhat safer.

It is a lot to swallow all at once, but it sounds like you have a fair grasp 
of the tools. At this point, it's less a matter of the Xilinx docs than it 
is assumptions about the board. Take out the reset at the top level and set 
it to constant '1' in your code. Check the pin locations in the ucf. Take 
out the data-gate until you have it working. I didn't see an led_enable pin 
at the top level entity. Check the schematic and see that it is wired to 
ground rather than a pin.

On 16 mei, 22:52, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "gert1999" <ggd...@gmail.com> wrote in message
>
> news:af6b611f-0775-41ad-a664-ab6605364e88@o14g2000vbo.googlegroups.com...
> On 16 mei, 19:08, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
>
>
> > "gert1999" <ggd...@gmail.com> wrote in message
>
> >news:95580829-2b4b-4981-acb5-9489958899bd@v4g2000vba.googlegroups.com...
> > I've added some files on the same link
> > First you got the reset line correct: it should be driven low instead
> > of high (if reset=3D'0')
> > Second I added the common driving kathode pins. In the manual they
> > indicate they should all be driven low if not multiplexing. I've done
> > so, this could also be derived from the schematic as the are pnp
> > transistors. However I can't find any code in the handbook example:
> > how do they drive them low if there is no code written ? Setting
> > attributes might be the key ??
> > .
> > A new version of the source is the file teller_update1.txt
> > I placed screenshots of pinmapping, low level simulation of the
> > counter, and top level simulation of the whole design
>
> > As one can see: the counter counts, but the LEDs are not being
> > driven ?? They just stay low resulting in adeadboard
> > What exactly do you mean by pull down atributes ? I only specified
> > clock_ext DATA_GATE as they did so in the manual
>
> > =3D=3D=3D=3D=3D=3D=3D=3D
> > You're now looking in the right places, and asking the right questions.
> > The
> > next step is to answer them yourself. ;)
>
> > Pullup and pulldown apply more to reading switches; don't let me confus=
e
> > you
> > with my confusion. Data-gate is related to power save modes. Try disabl=
ing
> > it removing the attribute, or make sure its driven correctly. Try drivi=
ng
> > a
> > constant '0' on the common cathode. Failing that, physically tie it to
> > ground on theboard. Try probing with a meter and look for voltages you
> > would expect. The LED pins should read somewhat less than half the high
> > state voltage. Check that the display cathode is grounded, not just
> > floating. Check that the data-gate pin reads whatever means not power
> > save.
>
> > Good luck.
>
> =3D=3D=3D=3D
> Thank's a lot for helping. =A0 I know about pullup and pulldown in
> simpel logic (active / passive pull up and that kind of things)
> I have been trying to answer the questions for several days and
> decided to ask help :-)
>
> I'll see what to do with it
> There are so many questions and Xilinx manuals are not very helpfull
> (they make it look so simple .. =A0)
>
> If it ever works I wil leave a mesage here (if the article will still
> be avaiilable in the newsgroup :-) )
>
> =3D=3D=3D=3D=3D=3D=3D
> Double check that reset pin. The testbench likely just needed a simple
> stimulus to take it out of reset, something like rst <=3D '0', while the =
code
> was actually fine. Read the schematic and be sure you have the right
> pullup/down sense on that pin. Same with data-gate. Probe the logic level=
s
> with a meter. If you have an I/O header available, route the signals to t=
he
> header to make probing easier and somewhat safer.
>
> It is a lot to swallow all at once, but it sounds like you have a fair gr=
asp
> of the tools. At this point, it's less a matter of the Xilinx docs than i=
t
> is assumptions about theboard. Take out the reset at the top level and se=
t
> it to constant '1' in your code. Check the pin locations in the ucf. Take
> out the data-gate until you have it working. I didn't see an led_enable p=
in
> at the top level entity. Check the schematic and see that it is wired to
> ground rather than a pin.

I solved the problem !
All I had to do is adding the following timing constraints

clock period 40 ns
offset before clock 10 ns
offset after clock 10 ns

It just works and had nothing but absolutely nothing to do with the
code
I wonder why the manual did not mention anything about this ?

I hope this might be usefull for someone else, that's the reason I add
this message on this thread

Thanks a lot for help

Gert

On May 27, 10:09=A0am, gert1999 <ggd...@gmail.com> wrote:
> On 16 mei, 22:52, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
>
>
> > "gert1999" <ggd...@gmail.com> wrote in message
>
> >news:af6b611f-0775-41ad-a664-ab6605364e88@o14g2000vbo.googlegroups.com..=
.
> > On 16 mei, 19:08, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
> > > "gert1999" <ggd...@gmail.com> wrote in message
>
> > >news:95580829-2b4b-4981-acb5-9489958899bd@v4g2000vba.googlegroups.com.=
..
> > > I've added some files on the same link
> > > First you got the reset line correct: it should be driven low instead
> > > of high (if reset=3D'0')
> > > Second I added the common driving kathode pins. In the manual they
> > > indicate they should all be driven low if not multiplexing. I've done
> > > so, this could also be derived from the schematic as the are pnp
> > > transistors. However I can't find any code in the handbook example:
> > > how do they drive them low if there is no code written ? Setting
> > > attributes might be the key ??
> > > .
> > > A new version of the source is the file teller_update1.txt
> > > I placed screenshots of pinmapping, low level simulation of the
> > > counter, and top level simulation of the whole design
>
> > > As one can see: the counter counts, but the LEDs are not being
> > > driven ?? They just stay low resulting in adeadboard
> > > What exactly do you mean by pull down atributes ? I only specified
> > > clock_ext DATA_GATE as they did so in the manual
>
> > > =3D=3D=3D=3D=3D=3D=3D=3D
> > > You're now looking in the right places, and asking the right question=
s.
> > > The
> > > next step is to answer them yourself. ;)
>
> > > Pullup and pulldown apply more to reading switches; don't let me conf=
use
> > > you
> > > with my confusion. Data-gate is related to power save modes. Try disa=
bling
> > > it removing the attribute, or make sure its driven correctly. Try dri=
ving
> > > a
> > > constant '0' on the common cathode. Failing that, physically tie it t=
o
> > > ground on theboard. Try probing with a meter and look for voltages yo=
u
> > > would expect. The LED pins should read somewhat less than half the hi=
gh
> > > state voltage. Check that the display cathode is grounded, not just
> > > floating. Check that the data-gate pin reads whatever means not power
> > > save.
>
> > > Good luck.
>
> > =3D=3D=3D=3D
> > Thank's a lot for helping. =A0 I know about pullup and pulldown in
> > simpel logic (active / passive pull up and that kind of things)
> > I have been trying to answer the questions for several days and
> > decided to ask help :-)
>
> > I'll see what to do with it
> > There are so many questions and Xilinx manuals are not very helpfull
> > (they make it look so simple .. =A0)
>
> > If it ever works I wil leave a mesage here (if the article will still
> > be avaiilable in the newsgroup :-) )
>
> > =3D=3D=3D=3D=3D=3D=3D
> > Double check that reset pin. The testbench likely just needed a simple
> > stimulus to take it out of reset, something like rst <=3D '0', while th=
e code
> > was actually fine. Read the schematic and be sure you have the right
> > pullup/down sense on that pin. Same with data-gate. Probe the logic lev=
els
> > with a meter. If you have an I/O header available, route the signals to=
 the
> > header to make probing easier and somewhat safer.
>
> > It is a lot to swallow all at once, but it sounds like you have a fair =
grasp
> > of the tools. At this point, it's less a matter of the Xilinx docs than=
 it
> > is assumptions about theboard. Take out the reset at the top level and =
set
> > it to constant '1' in your code. Check the pin locations in the ucf. Ta=
ke
> > out the data-gate until you have it working. I didn't see an led_enable=
 pin
> > at the top level entity. Check the schematic and see that it is wired t=
o
> > ground rather than a pin.
>
> I solved the problem !
> All I had to do is adding the following timing constraints
>
> clock period 40 ns
> offset before clock 10 ns
> offset after clock 10 ns
>
> It just works and had nothing but absolutely nothing to do with the
> code
> I wonder why the manual did not mention anything about this ?
>
> I hope this might be usefull for someone else, that's the reason I add
> this message on this thread
>
> Thanks a lot for help
>
> Gert

That is actually an odd solution to a problem that shows in
simulation.  Did you find other changes that were needed to the code.
I looked at the code and I don't see a reason for the led outputs to
all be zero if the decade counter is counting.  It appears that you
verified the decade counter and the top level led output separately.
Is there a reason why you didn't look at the decade counter output in
the top level simulation?

My guess is that there is something else wrong.  Until you can
simulate your code I would not trust that it is working correctly.

Rick

On May 28, 2:09=A0am, gert1999 <ggd...@gmail.com> wrote:
> I solved the problem !
> All I had to do is adding the following timing constraints
>
> clock period 40 ns
> offset before clock 10 ns
> offset after clock 10 ns
>
> It just works and had nothing but absolutely nothing to do with the
> code
> I wonder why the manual did not mention anything about this ?

Strange - CPLDs are usually the most timing agnostic.
(and you'd expect the tools to take a first guess at any timing)

You should be able to compare the two Fitter report files, to see just
how the
logic mapped, and play 'spot the difference' between the one that
worked, and the one that failed.

-jg