Re: [oc] C++ to HDLs? Thats fine for breakfast now give me a challenge for lunchtime

["Jim Dempsey" <dempsey@northnet.net>]

----- Original Message -----
From: "Paul McFeeters" <paul.mcfeeters@ntlworld.com>
To: <cores@opencores.org>
Sent: Monday, December 17, 2001 9:02 AM
Subject: RE: [oc] C++ to HDLs? Thats fine for breakfast now give me a
challenge for lunchtime


>
> To get around the problem of accessing values assigned to signals that are
> not updated till after the cycle finishes I have two ideas so far.
>
> 1. Assign the results to temporary variables and then copy them to the
relevant
> signals at the end of the cycle. I am concerned because surely there is
some
> sort of limit on how many times you can assign values to variables within
say
> a 10ns clock cycle. Any HDL experts wish to clue me in?
>

The use of temporary variables are a compile time issue not a run time
issue.
The use of a runtime variable is an expression of the current state of ...
For persistancy of the variable, the variable can be expressed as a latch.
The C to HDL can automaticaly construct the latch given a proper syntax.
As a hardware engineer you would not want to use a latch when one is not
required.

>
> The A|RT method smells of  macros and #defines, yuk!

The use of macros (#defines) are a good way to reduce programming error.
The use of C++ templates and classes are another way to reduce
programming errors. Both reduce the number of statements necessary
to perform the operation. For both, the declarations can be such that
at compile time you can differentiate between compile for simulator
and compile for HDL.

> My history is as a C/C++ programmer so I want it
> to be as close to ANSI-C as possible, that way its less work for existing
> C programmers to adjust their existing code for translation by my program.
>

That, in and of itself, is the problem. The execution of a C program (and
the thought process involved with the writting of said program) and the
abstraction of the hardware are two quite seperate abstractions of the
same problem. A C programmer might write

    void    bitAdder(
        IN BOOL inputA,
        IN BOOL inputB,
        IN BOOL inputCarry,
        OUT BOOL outputX,
        OUT BOOL outputCarry)
    {
        outputX = inputA ^ inputB ^ inputCarry;
        outputCarry = (inputA & inputB) | ((inputA | inputB) & inputCarry);
    }

But the hardware is likely to want

    extern  volitile IN BOOL inputA;
    extern  volitile IN BOOL inputB
    extern  volitile IN BOOL inputCarry;
    extern  OUT BOOL outputX;
    extern  OUT BOOL outputCarry;
    volitile void    bitAdderNameHere(
    {
        outputX = inputA ^ inputB ^ inputCarry;
        outputCarry = (inputA & inputB) | ((inputA | inputB) & inputCarry);
    }

Where the computation is continuous. As well as at times the output
values are undefined.

The conceptualization of the problem is quite different.
For simulation purposes bitAdder would be called during the simulation
at different time states. And possibly more than once during a time state.

The art of making the helper macros (or template or class deffinitions)
is the art of simplifying the comples.

I can see the use of C++ templates being of particularly handy in creating
the conversion language. And the use of macros to use the template
as a means to simplify the syntax too.

Jim Dempsey



--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml