Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
742 Views

Pin Assignments -- less tedious way?

I have a Cyclone III 3c120 development board and am using the terASIC Data Conversion Card on the HSMC. 

 

Is there any better way of getting the pin assignments than doing them manually one by one?
0 Kudos
10 Replies
Highlighted
Valued Contributor III
1 View

 

--- Quote Start ---  

I have a Cyclone III 3c120 development board and am using the terASIC Data Conversion Card on the HSMC. 

 

Is there any better way of getting the pin assignments than doing them manually one by one? 

--- Quote End ---  

Yes, you write a Tcl script to apply the pin constraints. 

 

I used to write a script called pinout.tcl that applied the pin constraints. Now I use a tcl script called constraints.tcl that applies pin and default I/O constraints. 

 

I've attached examples of the old style for the BeMicro and the new style for the BeMicro-SDK. I just haven't got around to updating the BeMicro script. I had to put the Tcl files in .zip format before I was allowed to post them. 

 

You source these files in Quartus, or in a quartus synthesis script, to apply the constraints. 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

Thanks for those helpful examples. I exported the assignments from "Assignment Editor" for an example project, and it looks like it's just a Tcl script. I looked through your attached files, and I imagine that at some point you had to reference the schematic and enter each pin manually. Is that correct? 

 

I know it's a one-time ordeal, but I was wondering if these assignments already existed. Particularly, it's confusing to go between the two schematics: the schematic for the HSMC card, and then the schematic for the development board.
0 Kudos
Highlighted
Valued Contributor III
1 View

 

--- Quote Start ---  

I exported the assignments from "Assignment Editor" for an example project, and it looks like it's just a Tcl script. I looked through your attached files, and I imagine that at some point you had to reference the schematic and enter each pin manually. Is that correct? 

 

--- Quote End ---  

The way I generate the files is to either start with a schematic, or start with an example design and export the pin assignments. The Altera constraints are waste of typing, so in constraints.tcl I use a short-hand "keyword=value" notation for the pin assignments and constraints, and then use Tcl loops to convert the keywords and values to Altera-specific Tcl constraints. 

 

 

--- Quote Start ---  

 

I know it's a one-time ordeal, but I was wondering if these assignments already existed. Particularly, it's confusing to go between the two schematics: the schematic for the HSMC card, and then the schematic for the development board. 

--- Quote End ---  

I always use the same design pin names (entity definition) for the top-level file, with all pins defined (regardless of whether the design uses them or not). For example, the HSMC connector would be generically named hsma_lvds_a etc. What those pins connect to is design-dependent and happens inside the top-level design file, i.e., hsma_lvds_a will get renamed or aliased to make the code easier to read. 

 

Try not to rename top-level pins to match an HDL design, as then you have to have a constraints file that depends on your design. Keep the top-level entity pin names the same, and simply connect them to new names at the top-level file in a project. 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

i also to try and use a single pinout for a board and use port mapping at the top level to make the "assignments"

0 Kudos
Highlighted
Valued Contributor III
1 View

 

--- Quote Start ---  

I know it's a one-time ordeal, but I was wondering if these assignments already existed. Particularly, it's confusing to go between the two schematics: the schematic for the HSMC card, and then the schematic for the development board. 

--- Quote End ---  

 

 

Often, among the dev kit's examples, there's a project with a skeleton top level and pin assignments for all the pins. 

That's what I usually search for first.
0 Kudos
Highlighted
Valued Contributor III
1 View

Hi thepancake, 

 

 

--- Quote Start ---  

i also to try and use a single pinout for a board and use port mapping at the top level to make the "assignments" 

--- Quote End ---  

Here's a question for you; what do you do with designs that contain transceivers?  

 

I'm working with the Stratix IV GX development kit, and I find it annoying that I can only have a top-level design with the transceiver and reference clock pins defined if they are actually connected to a transceiver block. This means I have to comment out the top-level entity pins for designs that do not use transceivers. I still leave the constraints in the design for those pins, but then I get ignored constraints warnings. 

 

If I just have to 'live with this', then I was going to look into splitting the synthesis process into an elaboration phase, extract the pin names actually used in a design, and then go through my constraints list of all pins, and only apply those constraints that have actual pins in the design. Then finish the P&R process. I think this should work (though I have not tested it). This would at least eliminate the ignored assignments warnings. 

 

With this scheme, I'd have constraints Tcl procedures that would be common to a specific board design (the GX development kit), but I'd have top-level entities that could be design-specific (include/exclude transceiver channels). 

 

Any recommendations? 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

i've run in to the same problems with transceiver assignments. at the moment i use the crude work around of commenting things in and out as needed

0 Kudos
Highlighted
Valued Contributor III
1 View

 

--- Quote Start ---  

i've run in to the same problems with transceiver assignments. at the moment i use the crude work around of commenting things in and out as needed 

--- Quote End ---  

Ok, thanks. If I get a better technique working, I'll post it to the forum. 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

maybe HDL embedded I/O assignments? at least you don't have to open the .qsf

0 Kudos
Highlighted
Valued Contributor III
1 View

 

--- Quote Start ---  

maybe HDL embedded I/O assignments? at least you don't have to open the .qsf 

--- Quote End ---  

Open a .qsf? Never use 'em, not on purpose anyway ;) 

 

My design process involves checking all code and a Tcl synthesis, timing, and simulation scripts into CVS. The Quartus Tcl script creates a tool-version specific build directory, and then all generated files go there. If I have to change a setting and I'm too lazy to look up the corresponding Tcl command, I'll use the Quartus GUI, generate a Tcl file for the project, and extract the appropriate Tcl commands and put them in my script. Similarly, I'll use the TimeQuest GUI to figure out what to put in my .sdc script. When done, I blow away all the Quartus build chaff. The nice thing about this approach is that its worked since MAX+PLUS II, and I never have to convert a project from one version of Quartus to the next. 

 

If I was to use embedded HDL I/O assignments, I think the top-level entities would start to look pretty darn ugly, and I really hate repeating myself ... I can live with copying and pasting the entity definition, but copying a bunch of embedded HDL assignments would be too much :) 

 

Having to comment out the transceiver pins annoys me, as it is a stupid decision to make in the synthesis tool. When a pin is unused in the design (and set to 0, 1, or Z), the synthesis tool can detect that, and then do whatever it is doing now (when the pin does not exist in the design). Of course, perhaps I'm just being grumpy :) 

 

Cheers, 

Dave
0 Kudos