FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 07-23-2008, 04:44 PM
Guest
 
Posts: n/a
Default 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


Reply With Quote
  #2 (permalink)  
Old 07-23-2008, 04:53 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

[email protected] 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
Reply With Quote
  #3 (permalink)  
Old 07-23-2008, 06:49 PM
ghelbig
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

On Jul 23, 8:53 am, Mike Treseler <[email protected]> wrote:
> [email protected] 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.
Reply With Quote
  #4 (permalink)  
Old 07-23-2008, 07:44 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

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
Reply With Quote
  #5 (permalink)  
Old 07-24-2008, 03:54 PM
ghelbig
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

On Jul 23, 11:44 am, Mike Treseler <[email protected]> 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.
Reply With Quote
  #6 (permalink)  
Old 07-24-2008, 04:22 PM
KJ
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

On Jul 24, 10:54*am, ghelbig <[email protected]> wrote:
> On Jul 23, 11:44 am, Mike Treseler <[email protected]> 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
Reply With Quote
  #7 (permalink)  
Old 07-24-2008, 04:55 PM
John McCaskill
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

On Jul 24, 8:22*am, KJ <[email protected]> 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
Reply With Quote
  #8 (permalink)  
Old 07-24-2008, 04:59 PM
KJ
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

On Jul 24, 11:55*am, John McCaskill <[email protected]> wrote:
> On Jul 24, 8:22*am, KJ <[email protected]> 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 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
Reply With Quote
  #9 (permalink)  
Old 07-24-2008, 06:29 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

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
Reply With Quote
  #10 (permalink)  
Old 07-26-2008, 01:18 PM
Paul Urbanus
Guest
 
Posts: n/a
Default Re: Quartus2 pin assignment

KJ wrote:
> On Jul 24, 10:54 am, ghelbig <[email protected]> wrote:
>> On Jul 23, 11:44 am, Mike Treseler <[email protected]> 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
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
assignment question Sen-Lung Chen Verilog 3 09-19-2005 04:28 AM
net extension in assignment chainastole Verilog 3 09-13-2005 04:53 PM
Quartus2 WEB: Simulating from test bench. Is that possible? Andre G. FPGA 2 09-06-2005 09:26 AM
Quartus2 V4.1 SP1 Rene Tschaggelar FPGA 6 09-09-2004 07:24 PM
Quartus2 4.1 SP1 Hangs Gary Pace FPGA 2 09-08-2004 05:36 AM


All times are GMT +1. The time now is 11:40 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved