Quartus Virtual Pin Assignment For Ic

How virtual prototyping enabled Altera’s SoC FPGAs

By Paul Dempsey |  1 Comment  |  Posted: February 12, 2013
Topics/Categories: Embedded - Architecture & Design, - Embedded Topics  |  Tags: FPGA, multicore, virtual prototype  | Organizations: Altera, Synopsys

The technique drove ‘agile systems development’ for the programmable logic vendor’s new product line.

This virtual prototyping case study addresses one of the programmable logic market's newest products. FPGA vendor Altera announced the availability of the first in its line of SoC FGPAs late last year, with further samples now being released during the first quarter of 2013.

The family combines a dual-core Cortex A9 alongside programmable logic on a 28nm die. Altera plans versions of the FPGA for markets such as communications, industrial, security, and medical.

Figure 1
SoC FPGA hard processor system (Source: Altera – click image to enlarge)

Development work began in mid-2011, and supporting software development began at the end of that year. The company made greater use of Synopsys flow-based virtual-prototyping techniques (Guide) during the development process than it had before, evolving an ‘agile systems development’ approach that draws on techniques used in agile software development.

Tech Design Forum spoke to Victoria Mitchell, senior manager for embedded software at Altera, about the design process.

Getting started in virtual prototyping

“This was a very different type of project for Altera,” she says, “and we looked at virtual prototyping to help us in a number of ways.”

First, the company wanted to explore more architectural tradeoffs than before ahead of making the final decision. “You have to get that choice right before you really proceed with the design,” says Mitchell.

Then, it wanted to develop a prototype that would allow software development to start well before the final RTL for the chip was available, and also enable hardware-software co-development. The ability to reduce the time it takes to get a chip and its related software to market is fundamental to the business case for virtual prototyping.

Altera chose a Synopsys-based virtual prototyping solution for a number of reasons, including the richness of the support.

“Synopsys already had the models you need for virtual prototyping, alongside the IP itself in its DesignWare library,” says Mitchell. “In a lot of cases like this, if the vendor has all that ready-to-go, it gets the business.

“Having industry support for transaction-level models (TLMs - Guide), and having them from several sources - other IP vendors, but also the processor core providers themselves - means that you can quickly put them together in a Lego-like way.”

As Altera was moving into full virtual prototyping, technical support was also important. “When we started, we didn’t have our Austin Technology Center [where much of the embedded software development ultimately took place]. It came later.

“Synopsys had the technical support to introduce our staff to virtual prototyping, but could also do much of the work, if needed, as we staffed up.

“Through its Services organization, it could give us the recommended path to follow as we developed our prototyping platform.”

Finally, Mitchell says it was important that Synopsys had tailored its tools to enable software development as add-ons rather than replacements for the tools its embedded team already used.

“These guys are creatures of habit. They want to work in familiar environments with their preferred debuggers. For example, it could be GDB [the GNU debugger], Lauterbach or DS-5 on the ARM side,” she says.

“The appeal of the Synopsys Virtual Platform is that it’s like your existing desktop. It extends the tools that you’re used to. You don’t have to learn something new. You just have to be introduced to it.”

Implementing a virtual prototyping flow

“My team has an unusual composition, though I think you’ll see it become more common,” says Mitchell. “I have the system modelers as well as the guys who write the device drivers. What we wanted to do was bring everyone together, get a very close relationship across the different disciplines.”

The first building block here was the way in which the industry and virtual prototyping as a technique have coalesced around SystemC (Guide) and the TLM 2.0 standard.

“If you get embedded people who are comfortable on the C++ side, you can ramp up pretty quickly with the right toolset. It means that there is a way for the different sides of the project to communicate,” Mitchell says.

The ultimate goal is not just to speed up discrete hardware and software development - although early access to a platform does bring that benefit – but to integrate the design processes.

“What you want is a situation where what happens on the hardware side can very quickly be influenced by, or influence, the software side, and the other way around. You want an active communication between the two sides,” says Mitchell.

“One example of what virtual prototyping enabled us to do here was the bridge between the SoC that we’ve integrated [and] the FPGA [fabric].”

The SoC element has a large amount of I/O – in fact, more virtual pins than there are actual pins coming out of the FPGA. Connecting the SoC element with the FGPA fabric therefore meant a lot of dynamic switching within the bridge between the two.

“Using virtual prototyping, the architects could go to the software team and say, ‘We’re thinking about doing this. Is it something you guys can manage?’ Because, from a software side, we owned control of the SoC elements, we could make suggestions. ‘Sure, we think we could do it with this type of multiplexing scheme.’ And then you can take those results and model them,” says Mitchell.

More recently, as its understanding of virtual prototyping has increased, Altera has tried to spread this kind of interplay still further.

“One of the best practices that we have adopted, and which we’re quite proud of, is that we now host our virtual platform on our automated server farm,” says Mitchell. “So, when we make changes to the source code, to the kernel and the device drivers, we can deploy those changes automatically to a suite of VPs and test them immediately.

“The reason we can do that is that the platform has standard controls and debugging information, and it’s available on multiple platforms, both Windows and Linux-based hosts.

“We can dynamically build and deploy to our virtual platform more easily than we can to a hardware-based emulator (Guide), and we can also run regression tests overnight, so that we ensure we have the highest-quality software.

“I think we’ve really capitalized on the integration aspect to automate our build infrastructure and our test infrastructure.”

Results

Using the Synopsys virtual-prototyping infrastructure and gradually building its own knowledge of the technique helped Altera complete development work on its SoC FPGA ahead of schedule.

“Our device taped out in September and the first silicon came back in November but we already had the software ready for it. We were in the Linux kernel for a device that had yet to come out,” says Mitchell.

Using virtual prototyping wasn’t just about accelerated time-to-market and revenue.

“Throughout the project, we had the ability to make tweaks and adjustments to the architecture and simultaneous adjustments on the software side,” she adds. “That meant we saw very rapid development iterations using the virtual prototyping tools.”

The platform also provides a way to bring up the new device’s supporting infrastructure, by sharing the increasingly mature prototype with key partners, so that both Altera’s and their enhancements would be in place as soon as silicon could be sent to customers.

“It wasn’t just that we were in the Linux kernel before silicon came back,” says Mitchell. “We were able to develop board support packages for a variety of applicable OSes. We had pre-silicon support for VXWorks, for MicroC/OS-II and for others.

“It was critical that we enabled as much of the ecosystem as possible as early as possible.”

This virtual platform also meant that Altera’s sales team had something to show to those potential customers.

“They had it out in the field, running from a laptop and helping us secure design wins before we even had the device back from the fab.”

Agile systems development

“Agile software development is a pretty powerful term that people have been talking about for a long time,” says Mitchell. “Agility in software is a really good way to make sure that you hit your requirements and make sure that you stand a chance of hitting your schedule.

“In our case, we saw that we could apply the same idea to a very complex SoC that had all this software that had to be developed for it at the same time. So we now see this as agile systems development, because you are bringing all these things together. We were able to rapidly change the prototype, rapidly change the software and deliver on time with a product that is going to meet market requirements.”

Because of its success on the SoC FPGA, Mitchell now regards virtual prototyping as a must-have and believes that its reach can be extended still further.

“We’ve already seen how we can reduce complexity using this agile systems approach. Going forward, it’s going to become more beneficial when we address even more complex problems, such as those related to power,” she says.

“Because we can make decisions before we tape out - ‘Does it make sense to have this as a piece of hard IP embedded in the die or do it as soft logic in the FPGA?’ - we can take performance measurements and see which one has the least latency, the least power draw over time, and make the decisions there.

“At the end of the day, not only will that save us from making critical errors in our architecture, it can also save us and our customers a fair amount of money.”

To find out more about the Synopsys solution for virtual prototyping, click here.

To find out more about the SoC FPGA family from Altera, click here.

If you use a modular Logic Lock Region design flow in your project, you may choose to make all the I/O pins in a module virtual I/O pins as a way to easily import the module in a top-level design. Also, if you want to compile an IP core to see how many resources it uses but it uses too many pins for your target device, making the pins virtual may allow the core to fit.

The following simple procedure makes all pins in your design virtual I/O pins. First, the design is synthesized to determine which nodes are pins. Next, a collection of name IDs is set to correspond to the pins in the design, then a assignment is applied to every pin. Finally, the export_assignments command writes all new assignments to the project's Quartus® II Settings File (.qsf).

The example uses the get_names and get_name_info commands, which are available beginning in version 4.0 of the Quartus II software (version 2.0 of the ::quartus::project package). Refer to the last example on this page for code that will work beginning with version 3.0 of the Quartus II software, and has more advanced capabilities.

load_package flow proc make_all_pins_virtual {} { execute_module -tool map set name_ids [get_names -filter * -node_type pin] foreach_in_collection name_id $name_ids { set pin_name [get_name_info -info full_path $name_id] post_message "Making VIRTUAL_PIN assignment to $pin_name" set_instance_assignment -to $pin_name -name VIRTUAL_PIN ON } export_assignments }

Improving the Sample Code

There are a variety of ways the sample code can be improved.

Remove Existing VIRTUAL_PIN Assignments

You can add the following command to the beginning of the procedure to remove all existing assignments. This is a useful step to ensure the assignments are in a known state. Add this command before the execute_module command.

remove_all_instance_assignments -name VIRTUAL_PIN

Manually Exclude Certain Pins, Such as Clocks

For the Quartus II software to perform timing optimization as it fits a design, the clocks have to be connected to top-level I/O pins in the target device, and the clocks must have clock settings applied. This is true even if all other pins in a design are virtual I/O pins. Therefore, the basic example above prevents the Quartus II software from optimizing timing during compilation because all pins, including clocks, have a assignment applied.

You can add a parameter to the procedure that accepts a list of signals to exclude from the assignments. This list would typically be the names of clock pins in your design. The following example accepts a list of names to exclude. It also includes the command to remove any existing assignments, discussed above.

load_package flow package require cmdline proc make_all_pins_virtual { args } { set options {\ { "exclude.arg" "" "List of signals to exclude" } \ } array set opts [::cmdline::getoptions quartus(args) $options] remove_all_instance_assignments -name VIRTUAL_PIN execute_module -tool map set name_ids [get_names -filter * -node_type pin] foreach_in_collection name_id $name_ids { set pin_name [get_name_info -info full_path $name_id] if { -1 == [lsearch -exact $opts(excludes) $pin_name] } { post_message "Making VIRTUAL_PIN assignment to $pin_name" set_instance_assignment -to $pin_name -name VIRTUAL_PIN ON } else { post_message "Skipping VIRTUAL_PIN assignment to $pin_name" } } export_assignments }

You can call the procedure with this command. This example assumes you have two clocks in your design, named and .

make_all_pins_virtual -exclude { clk_a clk_b }

Automatically Identify & Handle Clocks

The previous example to exclude certain signals has the disadvantage that they must be entered by hand. It is possible to determine clock signals with commands in the ::quartus::advanced_timing package. This package is available for loading in only the quartus_tan executable, so you must use quartus_tan to run scripts with the following example. The commands in this example are all supported beginning with version 3.0 of the Quartus II software.

Automatically identifying clocks has the advantage of allowing you to automate the application of the assignment. You can use the assignment in conjunction with the assignment to associate clock settings with clocks in your design. This provides the Quartus II Fitter with accurate information about timing requirements when you compile a design with virtual I/O pins. For more information about this assignment, refer to the Virtual Pin Clock logic option topic in the Quartus II Help.

The following example procedure makes all I/O pins in your design virtual I/O pins. It also makes virtual pin clock setting assignments where appropriate.

The example code first synthesizes your design. Then it attempts to delete any existing timing netlist before creating a new one. The get_timing_nodes commands create two collections of nodes from the timing netlist: and . The two collections are exclusive; no node in the collection is in the collection, even though the clock may be on an I/O pin.

The first foreach_in_collection loop gets the name of each pin in the design (excluding clock pins) and makes a assignment to it.

The second foreach_in_collection loop gets the name of each clock in the design. The get_instance_assignment command retrieves the corresponding clock setting, if it exists. If a clock setting for the clock does exist (the string is not empty), the script makes a assignment to the clock name with the value of the clock setting name.

load_package flow load_package timing load_package advanced_timing proc make_all_pins_virtual { } { remove_all_instance_assignments -name VIRTUAL_PIN remove_all_instance_assignments -name USE_CLK_FOR_VIRTUAL_PIN execute_module -tool map catch { delete_timing_netlist } create_timing_netlist -post_map set pin_ids [get_timing_nodes -type pin] set clk_ids [get_timing_nodes -type clk] # Make VIRTUAL_PIN assignments to every pin in the design foreach_in_collection pin_id $pin_ids { set pin_name [get_timing_node_info -info name $pin_id] post_message "Making VIRTUAL_PIN assignment to $pin_name" set_instance_assignment -to $pin_name -name VIRTUAL_PIN ON } # For each clock in the design, check whether it has a # corresponding CLOCK_SETTINGS assignment. foreach_in_collection clk_id $clk_ids { set clk_name [get_timing_node_info -info name $clk_id] set clk_stgs [get_instance_assignment -to $clk_name -name \ CLOCK_SETTINGS] # If there is a clock setting for this clock, make the # USE_CLK_FOR_VIRTUAL_PIN assignment if { ![string equal "" $clk_stgs] } { post_message "Making USE_CLK_FOR_VIRTUAL_PIN assignment \ to $clk_name with value $clk_stgs" set_instance_assignment -to $clk_name \ -name USE_CLK_FOR_VIRTUAL_PIN $clk_stgs } } export_assignments }

Design Examples Disclaimer

These design examples may only be used within Altera Corporation devices and remain the property of Altera. They are being provided on an “as-is” basis and as an accommodation; therefore, all warranties, representations, or guarantees of any kind (whether express, implied, or statutory) including, without limitation, warranties of merchantability, non-infringement, or fitness for a particular purpose, are specifically disclaimed. Altera expressly does not recommend, suggest, or require that these examples be used in combination with any other product not provided by Altera.

0 Replies to “Quartus Virtual Pin Assignment For Ic”

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *