On Thu, 2011-10-27 at 06:38 -0400, V G wrote:
> On Thu, Oct 27, 2011 at 2:44 AM, V G <x.solarwind.x@gmail.com> wrote:
>=20
> > [...]
> > The following is true:
> >
> > [...]
> > - In the -5 speed grade, the chip can run at up to 333MHz according to =
the
> > datasheet (I believe). My input clock (on the board) is a 50MHz oscilla=
tor.
> > I am instantiating a DCM to output a 300MHz clock via x6 multiplier. Wh=
en I
> > changed it to x5 multiplier (250MHz), it XST then *seems* to work the w=
ay I
> > expect it to, but I'm still not sure what's going on.
> > [...]
> >
>=20
>=20
> I randomly decided to add a global BUFG to my code and it *seems* to have
> fixed the observed problem of premature "resetting".
>=20
> This is what I did (non-relevant code removed):
>=20
> module main(clk, count, Led, seg, an);
>=20
> input wire clk;
> output reg [39:0] count =3D 0;
> [...]
>=20
> wire clkout2;
>=20
> clk0 clock(
> .CLKIN_IN(clk),
> .CLKFX_OUT(clkout)
> );
>=20
> BUFG  b1(
> .I(clkout),
> .O(clkout2)
> );
>=20
>=20
>=20
> I simply buffered the output of the DCM with a global buffer and then too=
k
> that signal as the final clock. I have NO idea why, but this *seems* to h=
ave
> fixed the observed problem. However, there may be some other issues going=
 on
> that I can't observe. I still don't know what the problem is and why addi=
ng
> a BUFG seems to have fixed it. Emphasis on SEEMS to have "FIXED" the
> "PROBLEM" since I really have no idea what the hell is going on with XST.

You REALLY need to read up on clocking in an FPGA.=20

All you did by adding the second BUFG (the DCM automatically will insert
a BUFG) is change the problem (adding the BUFG adds a slight delay to
the clock output by the DCM. You should not do that. If you've
configured your DCM correctly then the DCM, aside from multiplying up
your clock, has deskewed it in reference to the input clock. While
possible not important for your current design, this is critical when
your FPGA is trying to communicate with other chips running on the same
clock).

Chances are you design will stop working again later.

You should properly constrain your design before going further. The tool
will then tell you what paths are failing. Then you can work on
correcting what is wrong.

> In other news, Synplify seems to be driving pins that are not even in the
> design (decimal point LED seems to synchronously flash with the change of=
 a
> certain digit even though the pin is not even routed anywhere in the
> design).
>=20
> Synthesizing is driving me nuts. My code seems sane, but the synthesis
> doesn't seem to reflect that. Even worse, simulation takes forever. SIGH.

Simulation will not help for timing related issues, you have to work
with the hardware.

FWIW, the reason your design "works better" with Synplify is it by
default will infer clocks and implement clocking constraints (look at
the ncf file in the directory you edif is located, it will contain the
constrains generated by synplify).

The fact that you're getting weird behaviour is you're probably running
to fast.

TTYL

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.