Hi all, Is there a method for personalization of
ISE?
One of the personalizations:
      - For avoiding students to make errors in IOB proprties in UCF
files (the student's projects are for S3-Starter kit): is it possible
to add some step in the translate phase? I saw a perl interpreter
installed with ISE.

Cheers

you can create a script to check the pad report
(from par)  to make sure 
pin locations and IO standards are correct for your particular demo design
Aurash

GaLaKtIkUs™ wrote:
> Hi all, Is there a method for personalization of ISE?
> One of the personalizations:
>       - For avoiding students to make errors in IOB proprties in UCF
> files (the student's projects are for S3-Starter kit): is it possible
> to add some step in the translate phase? I saw a perl interpreter
> installed with ISE.
> 
> Cheers
> 

As someone who regularly writes code for existing
boards, I find it
annoying that ISE doesn't make it easier to find non-LOC'd I/O
pins.  I usually look first at the place&route report and check the
"number of LOCed IOBs" line to make sure it's 100%.  However there
is no translate option to report an error for non-LOCed I/O's.  Also
it's painful to browse through the pad report, which shows
the the status (LOCATED or not) of each IOB in a far right column
that is generally off-screen without scrolling.

Conversely I regularly need to set the (advanced) uption "Allow
unmatched LOC constraints" so I don't need to create a new
ucf file for each design on the same board.  I'd really rather
the unmatched LOC's be allowed (possibly with a warning) as
a default, and un-LOCed IOB's to be (optionally) flagged as an
error.  For anyone designing code for existing hardware, these
defaults make more sense.  Note that this includes anyone
using the Starter Kits, read inexperienced designers.

Just my 2 cents,
Gabor

Aurelian Lazarut wrote:
> you can create a script to check the pad report (from par)  to make sure
> pin locations and IO standards are correct for your particular demo design
> Aurash
>
> GaLaKtIkUs=99 wrote:
> > Hi all, Is there a method for personalization of ISE?
> > One of the personalizations:
> >       - For avoiding students to make errors in IOB proprties in UCF
> > files (the student's projects are for S3-Starter kit): is it possible
> > to add some step in the translate phase? I saw a perl interpreter
> > installed with ISE.
> >=20
> > Cheers
> >

Hi Gabor,
why a non-locked pin should be considered an error?
if you want to constrain a pin to a location, the tools will (usually) 
obey, if you do not care by not adding a location constraint why the 
tools should care, or maybe you want a mechanism which will guess that 
you actually forgot an entry into your ucf.

Aurash


Gabor wrote:
> As someone who regularly writes code for existing boards, I find it
> annoying that ISE doesn't make it easier to find non-LOC'd I/O
> pins.  I usually look first at the place&route report and check the
> "number of LOCed IOBs" line to make sure it's 100%.  However there
> is no translate option to report an error for non-LOCed I/O's.
   Also
> it's painful to browse through the pad report, which shows
> the the status (LOCATED or not) of each IOB in a far right column
> that is generally off-screen without scrolling.
> 
> Conversely I regularly need to set the (advanced) uption "Allow
> unmatched LOC constraints" so I don't need to create a new
> ucf file for each design on the same board.  I'd really rather
> the unmatched LOC's be allowed (possibly with a warning) as
> a default, and un-LOCed IOB's to be (optionally) flagged as an
> error.  For anyone designing code for existing hardware, these
> defaults make more sense.  Note that this includes anyone
> using the Starter Kits, read inexperienced designers.
> 
> Just my 2 cents,
> Gabor
> 
> Aurelian Lazarut wrote:
> 
>>you can create a script to check the pad report (from par)  to make sure
>>pin locations and IO standards are correct for your particular demo design
>>Aurash
>>
>>GaLaKtIkUs™ wrote:
>>
>>>Hi all, Is there a method for personalization of ISE?
>>>One of the personalizations:
>>>      - For avoiding students to make errors in IOB proprties in UCF
>>>files (the student's projects are for S3-Starter kit): is it possible
>>>to add some step in the translate phase? I saw a perl interpreter
>>>installed with ISE.
>>>
>>>Cheers
>>
>>>
> 
> 
> 

Aurelian Lazarut (a...@xilinx.com) wrote:
: Hi Gabor,
: why a non-locked pin should be considered an error?
: if you want to constrain a pin to a location, the tools will (usually) 
: obey, if you do not care by not adding a location constraint why the 
: tools should care, or maybe you want a mechanism which will guess that 
: you actually forgot an entry into your ucf.

What'd be really nice would be for the tools to let the user specify the 
severity of a condition on a per project basis.  So for example a non 
LOCed IO could be flagged as 'no action', 'warning' or 'error'

Given how many spurious warnings are often kicked out by the tools, it'd 
be really usefull to have this as an integrated feature.

cds

c d saunter wrote:
> Aurelian Lazarut (a...@xilinx.com) wrote:
> : Hi Gabor,
> : why a non-locked pin should be considered an error?

The reason a non-LOCed pin is an error on a board that has already
been placed routed and assembled, is that the tools will take this
I/O and assign it to any available I/O pin of the FPGA.  This can be
very bad depending on the net connected to the essentially randomly
selected pin.  Also sometimes non-LOCed IOB's represent signals
that were unintentionally assigned an I/O buffer.

Obviously I can constrain a pin to a location.  Sometimes I mis-spell
a pin name in a design (vs. a standard .ucf for the board).  In a
design
with for example an XC2V1000 with 300 or more used IOB's, it
is easy to mess one up.  Another problem is when using bused
I/O and the .ucf doesn't use the same type of brackets as XST.
Since the bracket style is a synthesis option, it's possible for
the same source code to work in one project and not another.

> : if you want to constrain a pin to a location, the tools will (usually)
> : obey, if you do not care by not adding a location constraint why the
> : tools should care, or maybe you want a mechanism which will guess that
> : you actually forgot an entry into your ucf.
>

The tools don't need to "guess", either there is or isn't a ucf entry
to
match each IOB in the design.

> What'd be really nice would be for the tools to let the user specify the
> severity of a condition on a per project basis.  So for example a non
> LOCed IO could be flagged as 'no action', 'warning' or 'error'
>
> Given how many spurious warnings are often kicked out by the tools, it'd
> be really usefull to have this as an integrated feature.
> 
> cds