pinout

Hi,

I would like to know the flow (either for Altera or Xilinx) to freeze
the FPGA pinout before the P&R phase is complete.
One safe assumption is that all timing issue will be taken care inside
of the FPGA without any changes to the pinout.

Regards,

http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.html#wp244527 

On Jul 1, 6:05=A0am, "Symon" <symon_bre...@hotmail.com> wrote:
> http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm...

I've always used the NET keyword, as opposed to PIN, e.g.:

NET top_level_port_name LOC =3D "A23";

I'm not sure about the assumption that all the timing issues will be
taken care of by the tools, though. Letting the tools choose the
pinout, and then locking them down, might be safer.

On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm...

Thanks, but I was not asking about the setting up the constraints for
fpga pinouts, it was a larger question.
How do I ensure that I have got a fairly accurate pinout (assuming
meeting timing is not an issue) when
the design is still under development. Do people create dummy FPGA top
and use special tools that only
check the validity of the pinouts wrt to the selected device?

Look at it this way - people in S/W world exchange information about
each other's module
by providing the class prototypes and this happens much before the
code has been developed.

Regards,

On Jul 1, 9:40=A0am, Sharanbr <sharan.basa...@gmail.com> wrote:
> On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>
> >http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm...
>
> Thanks, but I was not asking about the setting up the constraints for
> fpga pinouts, it was a larger question.
> How do I ensure that I have got a fairly accurate pinout (assuming
> meeting timing is not an issue) when
> the design is still under development. Do people create dummy FPGA top
> and use special tools that only
> check the validity of the pinouts wrt to the selected device?
>
> Look at it this way - people in S/W world exchange information about
> each other's module
> by providing the class prototypes and this happens much before the
> code has been developed.
>
> Regards,

You should look at the datasheet and user guide for the device you're
using, and understand the functionality of the different types of pins
it has. Then, you can start deciding which pins can go where. Board
layout concerns and I/O standards come into play as well.

Sharanbr escribi�:
> On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>> http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm...
> 
> Thanks, but I was not asking about the setting up the constraints for
> fpga pinouts, it was a larger question.
> How do I ensure that I have got a fairly accurate pinout (assuming
> meeting timing is not an issue) when
> the design is still under development. Do people create dummy FPGA top
> and use special tools that only
> check the validity of the pinouts wrt to the selected device?
> 
> Look at it this way - people in S/W world exchange information about
> each other's module
> by providing the class prototypes and this happens much before the
> code has been developed.
> 
> Regards,

In XILINX, PACE or PLANAHEAD, allow you to define your pintout and do a 
basic ERC, but beware you must use good placement rules or you fall into 
implementations errors after;

Walter

Sharanbr wrote:
> On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>> http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm...
> 
> Thanks, but I was not asking about the setting up the constraints for
> fpga pinouts, it was a larger question.
> How do I ensure that I have got a fairly accurate pinout (assuming
> meeting timing is not an issue) when
> the design is still under development. Do people create dummy FPGA top
> and use special tools that only
> check the validity of the pinouts wrt to the selected device?
> 
> Look at it this way - people in S/W world exchange information about
> each other's module
> by providing the class prototypes and this happens much before the
> code has been developed.
> 
> Regards,

There are comprehensive IO Planning tools in the ISE software.  There is 
an overview here for both pre-synthesis and post-synthesis:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ise_c_pin_assignment_overview.htm

Ed McGettigan
--
Xilinx Inc.

Dave <dhschetz@gmail.com> wrote:

>On Jul 1, 9:40=A0am, Sharanbr <sharan.basa...@gmail.com> wrote:
>> On Jul 1, 3:05 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>>
>> >http://www.xilinx.com/itp/xilinx7/books/data/docs/cgd/cgd0140_101.htm...
>>
>> Thanks, but I was not asking about the setting up the constraints for
>> fpga pinouts, it was a larger question.
>> How do I ensure that I have got a fairly accurate pinout (assuming
>> meeting timing is not an issue) when
>> the design is still under development. Do people create dummy FPGA top
>> and use special tools that only
>> check the validity of the pinouts wrt to the selected device?
>>
>> Look at it this way - people in S/W world exchange information about
>> each other's module
>> by providing the class prototypes and this happens much before the
>> code has been developed.
>>
>> Regards,
>
>You should look at the datasheet and user guide for the device you're
>using, and understand the functionality of the different types of pins
>it has. Then, you can start deciding which pins can go where. Board
>layout concerns and I/O standards come into play as well.

Indeed, but you may still encounter surpises that are not in the
datasheet but can be found in appnotes. For instance: Xilinx has fast
clock sharing between IOBs on Spartan3 devices. These only work for
the top and botton IOBs, not the IOBs on the side. Also, many IOBs
share clock inputs. You can't use 2 different clocks for
inputs/outputs which share those clock lines.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Sharanbr wrote:
> How do I ensure that I have got a fairly accurate pinout (assuming
> meeting timing is not an issue) when
> the design is still under development. Do people create dummy FPGA top
> and use special tools that only
> check the validity of the pinouts wrt to the selected device?

The most simplistic method is just to create dummy toplevel design,
and do pinmapping to that file with the help of the tools and manual,
and run the basic DRC checks.

In bigger designs that is not usually enough. If complex clocking or big
amount of special blocks (serdes for example) are used I at least
recommend a toplevel that has clocking structures and the special blocks
instantiated. That file can be then run with the pinmapping trough the
normal P&R flow to make sure that it is implementable.

And for good PCB layout the pinmapping has to be loaded into PCB level
tools (Mentor I/O Designer etc.) and the new pinmapping has to be
verified again in the P&R flow after each modification.

--Kim

On Jul 2, 10:07 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> Sharanbr wrote:
> > How do I ensure that I have got a fairly accurate pinout (assuming
> > meeting timing is not an issue) when
> > the design is still under development. Do people create dummy FPGA top
> > and use special tools that only
> > check the validity of the pinouts wrt to the selected device?
>
> The most simplistic method is just to create dummy toplevel design,
> and do pinmapping to that file with the help of the tools and manual,
> and run the basic DRC checks.
>
> In bigger designs that is not usually enough. If complex clocking or big
> amount of special blocks (serdes for example) are used I at least
> recommend a toplevel that has clocking structures and the special blocks
> instantiated. That file can be then run with the pinmapping trough the
> normal P&R flow to make sure that it is implementable.
>
> And for good PCB layout the pinmapping has to be loaded into PCB level
> tools (Mentor I/O Designer etc.) and the new pinmapping has to be
> verified again in the P&R flow after each modification.
>
> --Kim

Thanks Everyone.

Would like to know how many times it happens that the pinouts (defined
early in the cycle) have to change after the p&r?
It would assume this would depend on:
1) how aggressive the timings are
2) how accurate was the flow used to define early pinout (as Kim
suggested having top level reset/clocking structures)

Do you agree with the assesement?