Quartus2 pin assignment

I have an .fx Xchange assignment file with FPGA pin assignments
(portnames,pin numbers, direction io type etc..) but not a top level
design file.
I want to auto generate the top level design file from the
assignments, which the pin assignment editor lets me do.


Now, when I import the .fx file into the pin assignment editor, all
the ports are assigned but their directions are not, even though the
directions are specified in the .fx file (input, output,
bidirectional).


My problem is that when I auto generate the top level file, the
directions are screwed up for some of the ports.


Does anyone know what to do?


Thanks

blakaxe@gmail.com wrote:

> Does anyone know what to do?

I would write my own vhdl entity code,
and I would enter the pin numbers manually.
into quartus.

  -- Mike Treseler

On Jul 23, 8:53 am, Mike Treseler <mtrese...@gmail.com> wrote:
> blak...@gmail.com wrote:
> > Does anyone know what to do?
>
> I would write my own vhdl entity code,
> and I would enter the pin numbers manually.
> into quartus.
>
>   -- Mike Treseler

I haven't entered pin numbers manually in years.  Too easy to make
mistakes, especially with pin counts in the K range.

I have one PERL script that parses a wirelist into a spreadsheet, and
another that turns the spreadsheet into a constraint file.

And Quartus supports Tcl scripts for pin number entry, that method
works "just fine" too.

G.

ghelbig wrote:

> I haven't entered pin numbers manually in years.  Too easy to make
> mistakes, especially with pin counts in the K range.
> I have one PERL script that parses a wirelist into a spreadsheet, and
> another that turns the spreadsheet into a constraint file.
> And Quartus supports Tcl scripts for pin number entry, that method
> works "just fine" too.

That makes good sense for pin numbers.
But direction should be inferred from the code,
and IO type and timing is a separate problem.

       -- Mike Treseler

On Jul 23, 11:44 am, Mike Treseler <mtrese...@gmail.com> wrote:
> ghelbig wrote:
> > I haven't entered pin numbers manually in years.  Too easy to make
> > mistakes, especially with pin counts in the K range.
> > I have one PERL script that parses a wirelist into a spreadsheet, and
> > another that turns the spreadsheet into a constraint file.
> > And Quartus supports Tcl scripts for pin number entry, that method
> > works "just fine" too.
>
> That makes good sense for pin numbers.
> But direction should be inferred from the code,
> and IO type and timing is a separate problem.
>
>        -- Mike Treseler

That's why I run it through the spread sheet; I set the I/O type
there.  Getting direction from the top level would be a good addition.

Timing is always a problem... :)

G.

On Jul 24, 10:54=A0am, ghelbig <ghel...@lycos.com> wrote:
> On Jul 23, 11:44 am, Mike Treseler <mtrese...@gmail.com> wrote:
>
> > ghelbig wrote:
> > > I haven't entered pin numbers manually in years. =A0Too easy to make
> > > mistakes, especially with pin counts in the K range.
> > > I have one PERL script that parses a wirelist into a spreadsheet, and
> > > another that turns the spreadsheet into a constraint file.
> > > And Quartus supports Tcl scripts for pin number entry, that method
> > > works "just fine" too.
>
> > That makes good sense for pin numbers.
> > But direction should be inferred from the code,
> > and IO type and timing is a separate problem.
>
> > =A0 =A0 =A0 =A0-- Mike Treseler
>
> That's why I run it through the spread sheet; I set the I/O type
> there. =A0Getting direction from the top level would be a good addition.
>
> Timing is always a problem... :)
>

I use the spreadsheet as basically the 'master' data set and put all I/
O information there.  I have columns in there for...
1. The basics: signal name, direction, pin number, setup, hold, clock-
to-output, propogation delay requirements.
2. Device specific options: I/O drive strength, slew rate,
termination, I/O voltage standard, fast input/output registers (and
any other properties that belong with a signal I/O).

Each of the things in #1 and #2 get a column in the spreadsheet.  Each
signal gets a row.

Various pages in that spreadsheet workbook produce the following
design artifacts that are then simply copy/pasted into the appropriate
tool.  The formulas on those pages produce text in the format required
by the tool (i.e. valid VHDL or TCL).

- Design top level port map (can be pasted into the VHDL file).
- Port map with the connections to the testbench instantiation of the
design.
- TCL script to load into the synthesis tool to set all of the
properties.

Since it's in a spreadsheet I can use formulas so that changes in one
area get reflected in all of the appropriate places.  Particularly
when it comes to calculating timing requirements this is useful
because you can have a completely different workbook page that defines
the clocks involved, DLL/PLL clock multiplier/divider values, setup/
hold requirements of the devices that the design will be talking to.
Deriving the timing requirements for the new design in this manner,
makes it a lot clearer to follow (and find calculation errors) than if
the calculations are done 'somewhere else' and only the end result
value is pasted into the tool.

In effect the spreadsheet is the master source of the information and
also directly produces design artifacts that are then copied into
other tools...and I suppose if there is a way to output the values in
the pages of a spreadsheet into separate files then the manual copy/
paste operation could be eliminated.

KJ

On Jul 24, 8:22=A0am, KJ <kkjenni...@sbcglobal.net> wrote:

<snip>

> In effect the spreadsheet is the master source of the information and
> also directly produces design artifacts that are then copied into
> other tools...and I suppose if there is a way to output the values in
> the pages of a spreadsheet into separate files then the manual copy/
> paste operation could be eliminated.
>
> KJ

OpenOffice has a scripting language that you could use to produce the
files from your spreadsheet.  I have used it so that I could have my
Make files call OpenOffice and have it create pdfs of our
documentation and put them where they belong when we make our EDK
distribution.

There is an active forum for OpenOffice at http://www.oooforum.org/
I received lots of help there when I was trying to get my project
working.

Regards,

John McCaskill
www.FasterTechnology.com

On Jul 24, 11:55=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
> On Jul 24, 8:22=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
>
> <snip>
>
> > In effect the spreadsheet is the master source of the information and
> > also directly produces design artifacts that are then copied into
> > other tools...and I suppose if there is a way to output the values in
> > the pages of a spreadsheet into separate files then the manual copy/
> > paste operation could be eliminated.
>
> > KJ
>
> OpenOffice has a scripting language that you could use to produce the
> files from your spreadsheet. =A0I have used it so that I could have my
> Make files call OpenOffice and have it create pdfs of our
> documentation and put them where they belong when we make our EDK
> distribution.
>
> There is an active forum for OpenOffice athttp://www.oooforum.org/
> I received lots of help there when I was trying to get my project
> working.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

Thanks for the tip

KJ

KJ wrote:

> In effect the spreadsheet is the master source of the information and
> also directly produces design artifacts that are then copied into
> other tools

Sounds good.
You and G. have convinced me to try this next time.

...and I suppose if there is a way to output the values in
> the pages of a spreadsheet into separate files then the manual copy/
> paste operation could be eliminated.

copy/paste is fine with me.
I don't do this often enough
to justify debugging a full automation.
Consider publishing an example .xls with just a few rows.

        -- Mike Treseler

KJ wrote:
> On Jul 24, 10:54 am, ghelbig <ghel...@lycos.com> wrote:
>> On Jul 23, 11:44 am, Mike Treseler <mtrese...@gmail.com> wrote:
>>
>>> ghelbig wrote:
>>>> I haven't entered pin numbers manually in years.  Too easy to make
>>>> mistakes, especially with pin counts in the K range.
>>>> I have one PERL script that parses a wirelist into a spreadsheet, and
>>>> another that turns the spreadsheet into a constraint file.
>>>> And Quartus supports Tcl scripts for pin number entry, that method
>>>> works "just fine" too.
>>> That makes good sense for pin numbers.
>>> But direction should be inferred from the code,
>>> and IO type and timing is a separate problem.
>>>        -- Mike Treseler
>> That's why I run it through the spread sheet; I set the I/O type
>> there.  Getting direction from the top level would be a good addition.
>>
>> Timing is always a problem... :)
>>
> 
> I use the spreadsheet as basically the 'master' data set and put all I/
> O information there.  I have columns in there for...
> 1. The basics: signal name, direction, pin number, setup, hold, clock-
> to-output, propogation delay requirements.
> 2. Device specific options: I/O drive strength, slew rate,
> termination, I/O voltage standard, fast input/output registers (and
> any other properties that belong with a signal I/O).
> 
> Each of the things in #1 and #2 get a column in the spreadsheet.  Each
> signal gets a row.
> 
> Various pages in that spreadsheet workbook produce the following
> design artifacts that are then simply copy/pasted into the appropriate
> tool.  The formulas on those pages produce text in the format required
> by the tool (i.e. valid VHDL or TCL).
> 
> - Design top level port map (can be pasted into the VHDL file).
> - Port map with the connections to the testbench instantiation of the
> design.
> - TCL script to load into the synthesis tool to set all of the
> properties.
> 
> Since it's in a spreadsheet I can use formulas so that changes in one
> area get reflected in all of the appropriate places.  Particularly
> when it comes to calculating timing requirements this is useful
> because you can have a completely different workbook page that defines
> the clocks involved, DLL/PLL clock multiplier/divider values, setup/
> hold requirements of the devices that the design will be talking to.
> Deriving the timing requirements for the new design in this manner,
> makes it a lot clearer to follow (and find calculation errors) than if
> the calculations are done 'somewhere else' and only the end result
> value is pasted into the tool.
> 
> In effect the spreadsheet is the master source of the information and
> also directly produces design artifacts that are then copied into
> other tools...and I suppose if there is a way to output the values in
> the pages of a spreadsheet into separate files then the manual copy/
> paste operation could be eliminated.
> 
> KJ

I also use excel in a similar fashion, where each pin/signal gets a 
separate row and all of the various attributes of that pin are in columns.

One of the problems with having the tool take pin assignments and 
generate a top-level entity is the order of the signals. With an excel 
file, the top-level entity ports are ordered the same way as the in the 
excel file. The excel file also allows comments to be added to the 
top-level port signals for documentation purposes. I like to add a 
comment to each signal and also add comments before each logical signal 
group. Finally, the style/formatting of the top level entity to match 
the user's preferences is easily controlled by excel formulas.

The same concepts for formatting and comments also apply to the FPGA pin 
definition file. For me, that would primarily be a xilinx .ucf file. 
Some ancillary columns which I include in my excel pin list the 
schematic net name to which the port/pin is connected and any 
connector(s) to which the pin is attached. This information can then be 
included in either the top-level VHDL/verilog entity or the .ucf file.

I typically use cut/paste transfer the formulated text to the 
appropriate text file.

Urb