FPGA and PLC @myxilinx - Tumblr Blog

#jesd204

creator of elegant programs to replace awkward ones. As Mike puts it, good programs aren’t written or built. They’re grown

Or you could just chase the bastard. Run faster than him. Faster than the lab’s management. Don’t wait for someone else, do it yourself. Keep your boss happy, but don’t let him tie you down. Don’t give them a standing target.”

Dead ends are illusory. When did you ever let a ‘Do Not Enter’ sign keep you away from anything? Go around the brick walls. When you can’t go around, climb over or dig under. Just don’t give up.”

“But who’s going to pay my salary?”

“Permission, bah. Funding, forget it. Nobody will pay for research; they’re only interested in results,” Luie said.

When you’re doing real research, you never know what it’ll cost, how much time it’ll take, or what you’ll find. You just know there’s unexplored territory

Well, this seemed like a fun toy, so I dug into the accounting program. I discovered our accounting software to be a patchwork of programs written by long-departed summer students. Somehow, the hodgepodge worked well enough to be ignored. Looking at the mixture of programs, I found the software in Assembler, Fortran, and Cobol, the most ancient of computer languages. Might as well have been classical Greek, Latin, and Sanskrit.

As with most home-brew software, nobody had bothered to document our accounting system. Only a fool would poke around such a labyrinth without a map.

In retrospect it would have been better to go ahead and change the precedence of & to

higher than ==, but it seemed safer just to split & and && without moving & past an existing operator. (After all, we had several hundred kilobytes of source code, and maybe 3

installations....)

the order in which these groupings will be evaluated is always undefined. In the expression:

x = f() + g() * h();

The values returned by g() and h() will be grouped together for multiplication, but g and h

might be called in any order. Similarly, f might be called before or after the multiplication,

or even between g and h. All we can know for sure is that the multiplication will occur

before the addition (because the result of the multiplication is one of the operands in the

addition). It would still be poor style to write a program that relied on that knowledge. Most

programming languages don't specify the order of operand evaluation. It is left undefined so

that compiler-writers can take advantage of any quirks in the architecture, or special

knowledge of values that are already in registers

#c

Advice on Unsigned Types

Avoid unnecessary complexity by minimizing your use of unsigned types. Specifically,

don't use an unsigned type to represent a quantity just because it will never be negative

(e.g., "age" or "national_debt").

Use a signed type like int and you won't have to worry about boundary cases in the

detailed rules for promoting mixed types.

Only use unsigned types for bitfields or binary masks. Use casts in expressions, to make all

the operands signed or unsigned, so the compiler does not have to choose the result type.

#c

IP Upgrade Decisions

Typically when moving to a new version of the Vivado Design Suite, the Xilinx IP in your design will most likely be out-of-date and it will be locked. Each release of Vivado only delivers one version of each Xilinx IP. Locked IP cannot be re- customized nor be generated. If you had fully generated your IP as recommended in Sect. 3.4 , you can continue to use it as is since all the fi les needed for it are present. You can review the change log and product guide for the IP in your design and determine if you wish to upgrade to the current version or not. The changes can vary from simple constraint changes, possible bug fi xes, to the addition of new features. Some upgrades will require changes to your logic as the ports of the IP could change or the functionality might necessitate logic changes in your design. The process of upgrading is straightforward. Select the IP either in the Vivado RTL project in the IP Sources area or in the Managed IP project, and right click and select Upgrade IP . Once upgraded, you can proceed to generation of the output products. For speed and convenience, you can upgrade multiple IP in parallel.

#ipi

IP Constraints

Most Xilinx IP come with constraint fi les (.xdc). They can contain physical constraints such as setting IO standards or locations and timing constraints, such as false paths. These two types can be mixed in the same fi le. The constraints are written as if the IP were the top of the design. The constraints are automatically scoped to IP instance(s). It is strongly recommended that you do not modify the constraints delivered by an IP. There are two sources of constraints used by IP. If you’re a user of IP from the available catalog, you need not worry about this distinction. However, this distinc- tion would be of importance, if you are creating an IP of your own:

• XDC fi les created during generation of the IP and contained in the IP directory

or the Core Container

• Constraints created by Vivado automatically during the processing of the IP

#ipi

There are three ways in which to create an IP customization:

• Managed IP Project (recommended)

• Directly from within a Vivado RTL project

• Using Tcl script

Managed IP Project

It is recommended when working with IP that you use a Managed IP project. This is a special Vivado project specifi cally for creating IP customizations. The same IP

Catalog found in a Vivado RTL Project is provided to search for and customize IP. Each IP created is kept in its own folder with the user-provided name used during the customization. If you elect to use the Core Container feature (explained in Sect. 3.4.3 ), a single compressed binary fi le with the name given during customization with the extension of .xcix will be present. The IP folder or Core Container fi le

are stored outside of the Managed IP Project directory. The IP folder or Core Container fi le can be copied into a revision control system along with other design sources. If electing to use a folder for the IP, it is recommended that you place the entire folder and all contents into revision control. From the starting page of Vivado, select Manage IP (Fig. 3.3 ). You can either specify a new location on disk for a Managed IP Project or open an existing location.

Parameter Propagation

While designing with IPs in block design, it is important that the confi guration user parameters are propagated to the IP blocks connected. It enables an IP to auto- update its parameterization based on how it is connected in the design. For example, the clock frequency set in one of the IP blocks gets propagated through the design. IP can be packaged with specifi c propagation rules, and IP Integrator will run these rules as the block design is generated. However, if the IP cannot be updated to match properties based on its connection, an error is reported to highlight the poten- tial issues in the design.

#ipi

Packaging

IPI also provides a feature wherein you can package the entire block design after it has been validated and functionality has been proven. This allows you to reuse the IP block design in other projects as well. Figure 7.3 depicts the selection window for

packaging the project. Once the block design is packaged, the tool copies the necessary fi les in the speci- fi ed directory and adds the IP repository to the project locally. The properties associ- ated with the package can be changed while packaging the design, thus enabling you to use the block design in other projects.

#ipi

Design Reuse

With the complexity of the systems increasing exponentially, it becomes extremely important to be able to reuse designs with minor modifi cations to their systems without

the need to completely redo the design. IPI provides the right means to achieve this wherein it empowers you to confi gure the individual components as per the require- ment in your design to construct the different fl avors required for the system. It offers the ability to package your design which can be reused in other projects.

#ipi

Optimization Methodology

Any methodology for creating an optimal RTL implementation ideally requires understanding what the requirements of the RTL implementation are. However, the following methodology assumes you wish to create the highest-performing design.

If this is not the case, skip steps 4 and 5:

1. Simulate the C design and ensure the results are checked in the testbench.

2. Synthesize the C code to create a baseline design. This will be the default syn-

thesis performed by HLS and provide you with a starting point for optimization.

3. Apply the optimizations for interface synthesis. This ensures the interfaces are of

the required type to integrate the design with the rest of the system.

4. Apply pipeline directives.

5. Address any structural issues which create bottlenecks and prevent pipelining

achieving the desired II , such as partitioning arrays and unrolling loops.

6. Use the optimization directives which control the allocation of resources to

improve the area if this is required.

7. Finally, if the latency is a performance requirement, specify any latency directives.

#hls

Trending Blogs

Recently Viewed Blogs

FPGA and PLC