WP_Term Object
(
    [term_id] => 45
    [name] => Aldec
    [slug] => aldec
    [term_group] => 0
    [term_taxonomy_id] => 45
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 102
    [filter] => raw
    [cat_ID] => 45
    [category_count] => 102
    [category_description] => 
    [cat_name] => Aldec
    [category_nicename] => aldec
    [category_parent] => 157
)
            
WIKI Multi FPGA Design Partitioning 800x100
WP_Term Object
(
    [term_id] => 45
    [name] => Aldec
    [slug] => aldec
    [term_group] => 0
    [term_taxonomy_id] => 45
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 102
    [filter] => raw
    [cat_ID] => 45
    [category_count] => 102
    [category_description] => 
    [cat_name] => Aldec
    [category_nicename] => aldec
    [category_parent] => 157
)

Aldec Can Ensure Smooth System Integration

Aldec Can Ensure Smooth System Integration
by Luke Miller on 06-17-2014 at 9:00 pm

Tools, tools, tools. Designs are rapidly changing, JESD204b, Hybrid Memory cube and all other Gigabit serialization schemes are here to stay. RIP DDR. This means board level simulations with respect to firmware (FPGA) are going to be more challenging than ever. Why? you ask, especially if the board layout is simpler? True, but the data pipes are faster and wider, FPGAs denser, causing the board to do more in the same space. What tools are you going to use? I hate process but it is necessary.

Aldec has a neat tool that should place everyone on the same page within a team. Cowboys beware, this is not for you and you may find yourself at another ranch, move over Hoss. The tool is called ALINT. It is a VHDL/Verilog design rule checker. I know, it does not sound glamorous but let’s face it, the steps to successful design if often not to glamorous.

So let’s walk thru a real example. Say you are the team leader or product team lead for the firmware part of a surveillance RADAR. You are responsible for the beamformer, pulse-compressor, doppler filter. The requirements are traced and you get 6 guys and/or gals for the firmware design of the FPGAs. Two people per function. Now, unguided your beamformer VHDL/Verilog will look very different from the doppler or pulse-compressor teams. For the FPGA clock, some may call it clk, Clock, clk_p. Reset may be called rstn, nrst, rst… Signal names may be a crap shoot. Some folks on the team may use state machines that have the ‘others’ clause, some may use every state. Some may use synchronous reset, some asynchronous, other’s using none assuming default to ‘0’ state. Now each design may simulate correctly and verified against a golden set of data generated by our good ole Octave (You thought I was going to say MATLAB… ok MATLAB too). So what is the issue? All the designs worked in simulation, and let each code their own style and way, why cramp their style? What kind of team leader do we have here? Quick call HR!

The problems, I can almost guarantee will arise during the best part of FPGA design, system integration. Having a common set of VHDL/Verilog design rules such as naming conventions, coding styles, state machine, reset, clocking, signal types… would go a long way on simplicity of debugging and finding errors that would not show up in RTL simulation but in integration such as that ‘Random’ word that is dropped every 14.6 seconds. The other benefit is anyone else can pick up the same code and understand it. How many times has that happened to you? You get the design thrown over the wall from another designer and yikes! You almost have to start from scratch.

There are many more benefits of ALINT such as custom rule creation, phase based linting (you cannot get to the next step until the simplest of warnings are fixed), DO-254/ED-80 support… Check out the tool over at Aldec, and give it a try. I truly wish I had a tool like this years ago!

lang: en_US

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.