Reply by Stephan Mueller●December 15, 20042004-12-15
Hi Marc,
many thanks for your suggestions! It worked, but afterwards I got some
problems with product terms. That's why I switched to buffers now. They can
be located anywhere in the CPLD, so that I am not that restricted anymore..
Greetings,
Stephan
"Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag
news:1103027985.683504.75530@f14g2000cwb.googlegroups.com...
> Stephan Mueller wrote:
> > Hi,
> >
> > I have a quit simple question abaut cpld fitting:
> > I'm using a Xilix Coolrunner (XPLA3) CPLD with pin locking and trying
> to
> > access a SRAM.
> > If I try to fit my code, the following error message is given by the
> fitter
> > for some pins:
> >
> > WARNING:Cpld:1081 - Cannot assign signal 'sram_data<22>' to location
> > '73=FB16_3'. Not enough control terms.
> >
> > Searching the Xilinx answer data base I came across a posting (
> >
> http://university.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=19477
> > ) in which this problem was described and the following workaround
> was
> > presented:
> >
> > Adjust the design to remove unnecessary unique control term usage
> (for
> > example, use synchronous reset or preset as opposed to asynchronous
> reset or
> > preset, and use synchronous load as opposed to asynchronous load).
> >
> > Unfortunalty I don't know what a "synchronous reset or preset "
> means! Does
> > this means that I have to have an synchronous reset for the cpld
> device
> > (which I have) or does this mean that the macrocell itself should
> somehow be
> > reseted synchonously? And how do I do that??
>
> Howdy Stephan,
>
> They are referring to the reset for the flip-flop in the macrocell.
>
> I'm a tad rusty on CPLD design, so I don't know how much it is really
> hurting you, but it looks like you are inferring latches rather than
> FF's on a number of your signals. Latches typically require extra
> feedback, which can chew up extra resources. Since on CPLD"s most of
> the inputs already feed into the interconnect, this is probably less of
> an issue, but it still might be pushing you over the edge.
>
> To get around this, every signal that has assignment within the reset
> clause should also have an assignment after the "else" that is
> associated with your synchronous reset (which I couldn't help but
> notice is commented in your code).
>
> You can do this by either assigning all signals in each and every one
> of your states, or you can make a default assignment (so you only have
> to do it once) immedately before the case statement.
>
> Have fun,
>
> Marc
>
> >
> [...]
> >
> --////////////////////////////////////////////////////////////////////////
//
> > ///////////////
> >
> > if (CLK'event and CLK = '1') then
> >
> >
> --////////////////////////////////////////////////////////////////////////