Impulse Accelerated Technologies is pleased to announce the release of CoDeveloper Version 3.60 for the Windows and Linux operating systems.

New in this release:

• New PSPs: Xilinx Virtex-6 APU and PLB v4.6
• Updated online tutorials for Xilinx ISE 11.2
• CoValidator usability improvements
• No limit to width of streams in desktop simulation
• Bug fix: Multidimensional array offsets calculated with missing bits
• Bug fix: Five bits used to compare 64-bit integers
• Bug fix: Maximum number of predicates exceeded

A complete changelist can be found in the "Version History" section of the CoDeveloper User Guide.

Users with an up-to-date maintenance contract can download the release and find installation instructions here:

http://www.ImpulseAccelerated.com/ReleaseFiles/

Please send any feedback or problem reports to support@impulsec.com, or post them to the Impulse Support Forum at http://impulse-support.com/forums/.

Hi John,

This bug will be fixed in the upcoming 3.60 release.

Regards,
Ralph

Almost all of the example projects that ship with CoDeveloper use the CSP model. The Impulse C API provides methods for streaming and process creation that let you implement CSP.

Regards,
Ralph

Hi Gloria,

We do plan to support the other interfaces, but there's no planned release date yet. The next revision will likely add the creation of trace files during desktop simulation for register and signal interfaces. Producing accurate HDL testbenches for these interfaces is somewhat difficult, due to their unsynchronized nature.

Limitations of the current version of CoValidator can be worked around by editing the generated HDL testbench. Register, signal, and memory ports are left unconnected in the testbench, so you can add stimulus code for those interfaces.

Ralph

Yes, I would recommend using custom macros for your 18-bit type. You can use co_uint18 to contain the bits. Fixed-point arithmetic consumes much fewer resources than floating-point.

Ralph

To clarify: you can cause the evaluation of all the if-else conditions in a block to be computed concurrently (as possible), ignoring the C language requirements for short-circuit evaluation, by applying the CO FLATTEN pragma to the block.

This still doesn't allow you to scatter mutually exclusive conditionals throughout your code, but I believe it may help address the design problem you are after.

Sorry, there's no way to do this in Impulse C other than to use an if-else if block.

These signals are part of the Impulse C stream (co_stream) interface. Look for the section "Impulse C Input/Output Interfaces" in the "CoDeveloper User Guide".

I would take a look at BlueCat Linux and the PSP we offer for it, as I suspect it may use a similar driver. The relevant source and Makefiles are in %IMPULSEC_HOME%\Architectures\Xilinx\MicroBlaze\BlueCat\. There is also documentation for a BlueCat example here:

http://www.ImpulseAccelerated.com/ReadyToR...ECAT_MBLAZE.pdf

(We don't officially support Petalinux.)

Regards,
Ralph

The best way to do this is to call co_register_write at the beginning of a hardware process, before any other statements. The register will be written with the value quite soon after reset in this case.

Hi Ross,

There is a Mersenne Twister random number generator implemented in the CoDeveloper installation's Examples/Scientific/MersenneTwister32 project.

Regards,
Ralph

Thanks for the report, John. I'll try to reproduce this with the latest compiler release.

Regards,
Ralph

Hi Juanma,

The 'clk' signal in the ModelSim shot is running at a different rate than 'sclk'... did you generate the design with dual clocks? The 'sclk' input is unused (left open) by default.

If the input comes in every clock cycle, the output should also issue new output each clock (after an initial latency to fill the pipeline).

Ralph

There's your problem right there. Make sure the same datatype is used in all calls to co_stream_open and co_stream_create for the "invIn" stream.

Ralph

Hi Nelson,

The FXMUL32 macro normally requires a 64-bit intermediate result, and is defined for PLB-based platforms, but not FSL-based platforms. We're investigating the best solution, but a quick workaround would be to try copying the macro definition from %IMPULSEC_HOME%/Include/co_math.h into Filter_sw.c.

Regards,
Ralph

In what way does the simulation not work? Do you see an error message at compile time? At run time? Have you tried to use a debugger on the simulation program?

There is a Pico API for moving data on the host to/from the FPGA. Look at a Ready To Run example for the Pico E-16 platform, which uses the same host library as the E-14:

http://www.impulseaccelerated.com/ReadyToR...er_Pico_E16.zip

Ralph

Hi Jonathan,

Please use UNIX-style directory separators: '/'. If you enter such paths directly in the Project Options dialog's Build tab, all should be well.

Regards,
Ralph

Hi Nelson,

What are the warning messages EDK gives you?

Ralph

This looks good. Do you have some software processes to test the code, by sending and receiving pixel data? CoDeveloper ships with several projects that read/write BMP-format image files for testing such filters, for example EdgeDetect5X5.

How you get data to/from the FPGA depends on the FPGA platform you're using. What kind of board do you have?

Regards,
Ralph

Improvements to the GiDEL PSP are in development in concert with the University of Florida's CHREC lab. I can send you an updated PSP and some documentation this week via personal message on this forum.

Which board are you using?

It means a multiplier will be inferred with a longer latency, but that breaks the operation down to a sum of products of, say two 16x16 multiplies for a 32x32 operation. This might let your clock run faster.

Ralph

Hi Ramona,

You'll want to compile only software source files for the embedded processor, rather than the hardware source file you reprinted in your post. If you target your Impulse C project to a PowerPC-based Platform Support Package, such as "Xilinx Virtex-4 APU (VHDL)", the proper source files for the PowerPC, including driver code, will be generated and exported when you run the "Export Generated Hardware" and "Export Generated Software" commands from CoDeveloper.

I would suggest following one of the tutorials for the ML403 development board for an overview of the entire process of building the hardware and software portions of an Impulse C application using CoDeveloper and Xilinx Platform Studio:

http://www.impulseaccelerated.com/Tutorials/Xilinx/

Regards,
Ralph

Hi Jonathan,

Did you try adding a default case to each switch block in the code sample above?

I'm not sure if constant propagation will collapse the switch to nothing when you switch on a constant value. You could try, and see how the generated HDL changes. This is like reading assembly code, but scarier Stage Master Explorer should also be able to show you, in a friendlier graphical way, what the resulting hardware blocks will look like.

Ralph

Hi Jonathan,

Looks like SFL sockets are implemented using Windows Sockets (WinSock) on Windows. WSAGetLastError and the usual suspects, such as htons and gethostbyname, are provided by the WinSock library, so you'll have to link it with your desktop simulation. I believe the linker option you'll want is '-lws2_32', which can be added to the "Additional linker options" field in the Project Options dialog's Build tab.

The reason you don't run into this in VS is that it automatically links many Windows libraries if you use the default project settings.

Ralph

Thanks for joining the discussion, Jonathan!

Resource sharing isn't automatic with Impulse C--there aren't any compiler mechanisms to automatically share the hardware implementation of an operator or primitive function between uses of one in your code.

You could share the multiplier in your code example by doing a single multiply in a small loop over an array of operands. Or you could write an HDL function that feeds both pairs of operands through the same multiplier, then call that HDL function from C using the CO IMPLEMENTATION pragma.

The CO SET pragma usage Jonathan mentions is for specifying resource usage, in particular DSP vs. logic-based multipliers. It can be handy when you want to explicitly control which multipliers use the faster DSP blocks (which can be scarce), for example.

Ralph