a discussion about verification

Discussion in 'VHDL' started by mohammed rafi, Aug 14, 2004.

  1. hi,

    i have not seen any message about verification posted in both
    comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    about verification.
    can you pepole tell me how to verify a generic microprocessor. if you
    give me the verification plan, testplan and the list of corner cases
    it will be very useful.

    cheers,
    m. rafi
     
    mohammed rafi, Aug 14, 2004
    #1
    1. Advertising

  2. mohammed rafi wrote:


    > can you pepole tell me how to verify a generic microprocessor.


    Do you mean testing of the correct imlementation of all instructions
    with "verification"?
    If yes - just write a program that covers everything at a functional
    level: Test of every instruction with every possible processor flag set
    / reset and every addressing mode plus every exception.


    It might be helpful to put all expected results into the test program -
    example for Assembler (MSP430):

    mov #0x1234,R4
    mov #0x5678,R5

    ADD R4,R5 ;I want to test this ADD

    cmp #0x68AC,R5 ;expected result
    jeq good
    ;do error handling
    good: ...


    Ralf
     
    Ralf Hildebrandt, Aug 14, 2004
    #2
    1. Advertising

  3. mohammed rafi

    Jim Wu Guest

    Jim Wu, Aug 14, 2004
    #3
  4. Coverification is the best way.
    Cover all the instructions and addressing modes w/ tests.
    Write the tests in c.
    compile.
    convert the object to ascii hex.
    use verilog readmemh into program rom.
    build some small testbench w/ processor and rom and whatever.
    begin sim.
    If you develop Hardware Abstraction Layer you can use it
    1. in your tests.
    2. as library for final product.
    All your simulation code will be in c.
    If test reads something wrong (use assert macro) then you
    write some unique pattern to a unique location which will
    trigger sim to halt.






    "mohammed rafi" <> wrote in message
    news:...
    > hi,
    >
    > i have not seen any message about verification posted in both
    > comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    > about verification.
    > can you pepole tell me how to verify a generic microprocessor. if you
    > give me the verification plan, testplan and the list of corner cases
    > it will be very useful.
    >
    > cheers,
    > m. rafi
     
    Blackie Beard, Aug 15, 2004
    #4
  5. mohammed rafi

    john jakson Guest

    (mohammed rafi) wrote in message news:<>...
    > hi,
    >
    > i have not seen any message about verification posted in both
    > comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    > about verification.
    > can you pepole tell me how to verify a generic microprocessor. if you
    > give me the verification plan, testplan and the list of corner cases
    > it will be very useful.
    >
    > cheers,
    > m. rafi


    If you have the time to model the cpu in both HDL and Cycle C (RTL
    style) you can directly do most of the verification in C.

    You should have a compiler to gen bin code for cpu ISA and run that on
    the model to produce trace logs for all important busses,signals.
    These logs could run to millions of cycles. If you can boot an OS your
    in pretty good shape.

    Then its a matter of pruning down the tests to run on HDL to make sure
    HDL is same as Cycle C model bus by bus.

    Maintaining 2 models seems alot of trouble but you do get to do most
    of the work in a programming env in a tiny fraction of the time.

    Ofcourse you need a 3rd C model that is free of HW detail that is used
    to check the cycle C model too, opcode by opcode assuming cpu is in
    order design.

    regards

    johnjakson_usa_com
     
    john jakson, Aug 15, 2004
    #5
  6. Can you give me link to familiarize myself with "cycle c"?
    Never heard of it before.

    Regards,
    BB

    "john jakson" <> wrote in message
    news:...
    > (mohammed rafi) wrote in message

    news:<>...
    > > hi,
    > >
    > > i have not seen any message about verification posted in both
    > > comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    > > about verification.
    > > can you pepole tell me how to verify a generic microprocessor. if you
    > > give me the verification plan, testplan and the list of corner cases
    > > it will be very useful.
    > >
    > > cheers,
    > > m. rafi

    >
    > If you have the time to model the cpu in both HDL and Cycle C (RTL
    > style) you can directly do most of the verification in C.
    >
    > You should have a compiler to gen bin code for cpu ISA and run that on
    > the model to produce trace logs for all important busses,signals.
    > These logs could run to millions of cycles. If you can boot an OS your
    > in pretty good shape.
    >
    > Then its a matter of pruning down the tests to run on HDL to make sure
    > HDL is same as Cycle C model bus by bus.
    >
    > Maintaining 2 models seems alot of trouble but you do get to do most
    > of the work in a programming env in a tiny fraction of the time.
    >
    > Ofcourse you need a 3rd C model that is free of HW detail that is used
    > to check the cycle C model too, opcode by opcode assuming cpu is in
    > order design.
    >
    > regards
    >
    > johnjakson_usa_com
     
    Blackie Beard, Aug 17, 2004
    #6
  7. mohammed rafi

    john jakson Guest

    "Blackie Beard" <> wrote in message news:<fDdUc.47853$Lj.19051@fed1read03>...
    > Can you give me link to familiarize myself with "cycle c"?
    > Never heard of it before.
    >
    > Regards,
    > BB
    >
    > "john jakson" <> wrote in message
    > news:...
    > > (mohammed rafi) wrote in message

    > news:<>...
    > > > hi,
    > > >
    > > > i have not seen any message about verification posted in both
    > > > comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    > > > about verification.
    > > > can you pepole tell me how to verify a generic microprocessor. if you
    > > > give me the verification plan, testplan and the list of corner cases
    > > > it will be very useful.
    > > >
    > > > cheers,
    > > > m. rafi

    > >
    > > If you have the time to model the cpu in both HDL and Cycle C (RTL
    > > style) you can directly do most of the verification in C.
    > >
    > > You should have a compiler to gen bin code for cpu ISA and run that on
    > > the model to produce trace logs for all important busses,signals.
    > > These logs could run to millions of cycles. If you can boot an OS your
    > > in pretty good shape.
    > >
    > > Then its a matter of pruning down the tests to run on HDL to make sure
    > > HDL is same as Cycle C model bus by bus.
    > >
    > > Maintaining 2 models seems alot of trouble but you do get to do most
    > > of the work in a programming env in a tiny fraction of the time.
    > >
    > > Ofcourse you need a 3rd C model that is free of HW detail that is used
    > > to check the cycle C model too, opcode by opcode assuming cpu is in
    > > order design.
    > >
    > > regards
    > >
    > > johnjakson_usa_com


    I never looked at google but there's probably something there to read.

    Since C is generally free or low cost most companies will use C in
    different ways so these Cycle Cs are nonstandard.

    You also have the VCS compile to C option, and in the past I used a
    homebrew Verilog2C compiler. The resulting C was usually a few x
    slower than custom C and not very comprehensible. There is also
    SystemC.

    Since C is not a HDL and Verilog is not a gen purpose programming
    language there are constraints when using only one but there are
    issues if you use both.

    For the cpu I am working on which is < few K lines of HDL as well as
    the C compiler for it, I do the following.

    I forgo hierarchy since I also have to do layout, I need control of
    all final placement with hierarchy getting in the way. For a larger
    project this gets very hard. This is an FPGA not an ASIC and 1 person
    not a large team.

    I have a top level Verilog module that includes 3 files, nets.v,
    assign.v and always.v. The C source is almost the same, a main
    including nets.c, assign.c & always.c.

    There are also some define files that lets the net.v file declare all
    the wires and busses using something like

    wire16 which is changed to wire [15:0] etc for all the sizes needed.

    The nets.c file can now use the same declarations as the verilog with
    some changes. Arrays are special case again but most nets are not
    arrays.

    The reg vars are done in same way. In the def.h file both wire16 and
    reg16 just become ulong. That means another limit, nothing bigger than
    32b. Tough.

    The assign file will hold all continuosly assigned expressions off 1
    assign keyword. In Verilog these will be comma separated

    assign
    a = b, c= d,,,,,, etc ;

    In C this is almost exactly the same since many comma sep exprns are
    allowed.

    assign // assign is defined as null
    a = b, c= d,,,,,, etc ;


    The big difficulty here is bit level twiddling and use of {,,} and [:]
    and literal constants etc. For each case the code will be different,
    but most simple nets can be assigned with same code.


    Also use lots of ()? as syntax is same, these will usually become
    muxes.

    By definition the ordering of exprns in an always is unimportant in
    Verilog since they are event driven by the simulator, but the C
    compiler will eval them in order written.

    That means no cycle graphs can be allowed, every assigned var must be
    written before any use of that var and vars can only be assigned once.
    So the Verilog is forced to be in time event order as you expect
    signal propagation. This can get tough because now you need to think
    about what the schematic would look like for the signal propagation.
    For an FPGA there will be a constraint than no more than N assigns can
    stack up before the next flop where gate depth complexity is < some
    limit.



    The always is the same sort of thing but this time we want edge
    triggered flops vars. Either these can be explicitly made with 2
    assignments which can have the masters in any order, followed by all
    the slaves copies at the end hidden away.

    To be cheap & fast and to make V & C code more similar, I do the
    master/slave in 1 go by writing all assignments to flops in time
    reverse order.

    Verilog doesn't care about the order of always statements, one might
    prefer to write in the pipeline order flow, but for C that would
    produce a big tunnel short across the pipeline.

    So Verilog looks like

    always ... begin

    p3<=p2;
    p2<=p1;
    p1<=p0;

    end

    and C looks like same with always, begin, end defined as null,{,}

    always ... begin

    p3<=p2;
    p2<=p1;
    p1<=p0;

    end

    The expressions that are included here follow same rules as for
    assign. The same problem still persists with {,,,} [:] bit twiddling
    in Verilog since that must also be turned into shifts & mask &s.

    In some cases its not possible to do this master slave backwards with
    1 always write. IF you have a 4stage circular pipeline with logic
    between each stage, there is no logical end. One pipe must be noted as
    the end and its value can be assigned redundantly to an output net
    back over to the assign side. Now the next pipeline stage assigns from
    that net. Thats a hidden explicit master slave but using a reg and a
    net to hide it. Verilog & C don't care about redundant expressions,
    both compiler will remove them

    The C main includes the fake clock loop

    #include defs.h
    #include nets.c

    for (i=0;i<umpteen_clocks;i++) {
    #include assign.c // most computational logic

    fprintf(fp,"..",,,,); // lots of output goes here

    #include always.c // clock edge is effective here
    }

    Given the above, the verilog is fully synthesizeable and the C can
    cope with most of it pretty well. The 2 net files are almost identical
    except arrays.

    There is the issue of whether an expression should be placed in mostly
    the assign or the always side. If the expression has fanout >1 it must
    be in the assign side. In FPGA synthesis I sometimes sees different
    synthesis results depending on which side it is placed even if the sim
    result is same.


    No hierarchy, single clock domain, 32b widths & less, {,,} [:] issues
    but I expect the C to simulate maybe 100 x faster. It also has the
    advantage that a 2nd non RTL C model can also be included with no pain
    to verify the RTL model. In fact the compiler for the cpu could also
    be included to generate code for the ISA and be simulated on the
    models. Think of java/Jit/JVM here, cpu is the JVM.

    hope that helps

    johnjakson_usa_com
     
    john jakson, Aug 17, 2004
    #7
  8. mohammed rafi

    Chris Briggs Guest

    Well, there was a startup 4-5 years ago called C-Level Design that
    promoted a C-based design style called "Cycle C." They claimed
    incredible simulation speedups based on it and they had a tool to
    convert it to synthesizable Verilog RTL. Apparently either it didn't
    work too well or they couldn't convince anyone that it did, because if
    memory serves the company basically ran out of money and was acquired
    by Synopsys for a song. Synopsys dropped the products and said that
    some of C-Level's simulator technology would make its way into VCS.

    However, I'm not sure this is what john jakson was referring to. I
    think what he meant is a cycle-accurate C model. This would be a model
    of your cpu, written in C, that behaves correctly down to the
    interface level with cycle timing. I.e., internally it's a behavioral
    model that has no timing or delays and probably doesn't describe the
    actual internal organization. But you should be able to compare its
    interface behavior with the real RTL model and they should match.

    -cb


    "Blackie Beard" <> wrote in message news:<fDdUc.47853$Lj.19051@fed1read03>...
    > Can you give me link to familiarize myself with "cycle c"?
    > Never heard of it before.
    >
    > Regards,
    > BB
    >
    > "john jakson" <> wrote in message
    > news:...
    > > (mohammed rafi) wrote in message

    > news:<>...
    > > > hi,
    > > >
    > > > i have not seen any message about verification posted in both
    > > > comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    > > > about verification.
    > > > can you pepole tell me how to verify a generic microprocessor. if you
    > > > give me the verification plan, testplan and the list of corner cases
    > > > it will be very useful.
    > > >
    > > > cheers,
    > > > m. rafi

    > >
    > > If you have the time to model the cpu in both HDL and Cycle C (RTL
    > > style) you can directly do most of the verification in C.
    > >
    > > You should have a compiler to gen bin code for cpu ISA and run that on
    > > the model to produce trace logs for all important busses,signals.
    > > These logs could run to millions of cycles. If you can boot an OS your
    > > in pretty good shape.
    > >
    > > Then its a matter of pruning down the tests to run on HDL to make sure
    > > HDL is same as Cycle C model bus by bus.
    > >
    > > Maintaining 2 models seems alot of trouble but you do get to do most
    > > of the work in a programming env in a tiny fraction of the time.
    > >
    > > Ofcourse you need a 3rd C model that is free of HW detail that is used
    > > to check the cycle C model too, opcode by opcode assuming cpu is in
    > > order design.
    > >
    > > regards
    > >
    > > johnjakson_usa_com
     
    Chris Briggs, Aug 17, 2004
    #8
  9. mohammed rafi

    Chris Briggs Guest

    Well, there was a startup 4-5 years ago called C-Level Design that
    promoted a C-based design style called "Cycle C." They claimed
    incredible simulation speedups based on it and they had a tool to
    convert it to synthesizable Verilog RTL. Apparently either it didn't
    work too well or they couldn't convince anyone that it did, because if
    memory serves the company basically ran out of money and was acquired
    by Synopsys for a song. Synopsys dropped the products and said that
    some of C-Level's simulator technology would make its way into VCS.

    However, I'm not sure this is what john jakson was referring to. I
    think what he meant is a cycle-accurate C model. This would be a model
    of your cpu, written in C, that behaves correctly down to the
    interface level with cycle timing. I.e., internally it's a behavioral
    model that has no timing or delays and probably doesn't describe the
    actual internal organization. But you should be able to compare its
    interface behavior with the real RTL model and they should match.

    -cb


    "Blackie Beard" <> wrote in message news:<fDdUc.47853$Lj.19051@fed1read03>...
    > Can you give me link to familiarize myself with "cycle c"?
    > Never heard of it before.
    >
    > Regards,
    > BB
    >
    > "john jakson" <> wrote in message
    > news:...
    > > (mohammed rafi) wrote in message

    > news:<>...
    > > > hi,
    > > >
    > > > i have not seen any message about verification posted in both
    > > > comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    > > > about verification.
    > > > can you pepole tell me how to verify a generic microprocessor. if you
    > > > give me the verification plan, testplan and the list of corner cases
    > > > it will be very useful.
    > > >
    > > > cheers,
    > > > m. rafi

    > >
    > > If you have the time to model the cpu in both HDL and Cycle C (RTL
    > > style) you can directly do most of the verification in C.
    > >
    > > You should have a compiler to gen bin code for cpu ISA and run that on
    > > the model to produce trace logs for all important busses,signals.
    > > These logs could run to millions of cycles. If you can boot an OS your
    > > in pretty good shape.
    > >
    > > Then its a matter of pruning down the tests to run on HDL to make sure
    > > HDL is same as Cycle C model bus by bus.
    > >
    > > Maintaining 2 models seems alot of trouble but you do get to do most
    > > of the work in a programming env in a tiny fraction of the time.
    > >
    > > Ofcourse you need a 3rd C model that is free of HW detail that is used
    > > to check the cycle C model too, opcode by opcode assuming cpu is in
    > > order design.
    > >
    > > regards
    > >
    > > johnjakson_usa_com
     
    Chris Briggs, Aug 17, 2004
    #9
  10. mohammed rafi

    john jakson Guest

    (Chris Briggs) wrote in message news:<>...
    > Well, there was a startup 4-5 years ago called C-Level Design that
    > promoted a C-based design style called "Cycle C." They claimed
    > incredible simulation speedups based on it and they had a tool to
    > convert it to synthesizable Verilog RTL. Apparently either it didn't
    > work too well or they couldn't convince anyone that it did, because if
    > memory serves the company basically ran out of money and was acquired
    > by Synopsys for a song. Synopsys dropped the products and said that
    > some of C-Level's simulator technology would make its way into VCS.
    >
    > However, I'm not sure this is what john jakson was referring to. I
    > think what he meant is a cycle-accurate C model. This would be a model
    > of your cpu, written in C, that behaves correctly down to the
    > interface level with cycle timing. I.e., internally it's a behavioral
    > model that has no timing or delays and probably doesn't describe the
    > actual internal organization. But you should be able to compare its
    > interface behavior with the real RTL model and they should match.
    >
    > -cb
    >
    >


    snipping

    True, there were once half a dozen C companies showing their wares at
    DAC, don't think any survived. On John Cooleys website you can find
    some old anti C discussion. Most VLSI guys detest the thought of using
    C but as I said if you can live with the severe limits its not so bad
    for single clock small hierarchy etc. Wouldn't want to force it on
    anyone and its not easy to persude people to use something faster but
    is also not easy to use.

    My ideal solution would be a V compiler that is mostly C even a little
    C++ but with some verilog syntax & semantics added to it to make it
    possible to write RTL Verilog that but has cycle C perf but is also
    synthesieable. It might not have any event model to start.

    SystemVerilog does it the other way round and isn't done yet either.
    Too big for my tastes.

    regards

    johnjakson_usa_com
     
    john jakson, Aug 18, 2004
    #10
  11. "john jakson" <> wrote in message
    news:...
    > (Chris Briggs) wrote in message

    news:<>...
    > > Well, there was a startup 4-5 years ago called C-Level Design that
    > > promoted a C-based design style called "Cycle C." They claimed
    > > incredible simulation speedups based on it and they had a tool to
    > > convert it to synthesizable Verilog RTL. Apparently either it didn't
    > > work too well or they couldn't convince anyone that it did, because if
    > > memory serves the company basically ran out of money and was acquired
    > > by Synopsys for a song. Synopsys dropped the products and said that
    > > some of C-Level's simulator technology would make its way into VCS.
    > >
    > > However, I'm not sure this is what john jakson was referring to. I
    > > think what he meant is a cycle-accurate C model. This would be a model
    > > of your cpu, written in C, that behaves correctly down to the
    > > interface level with cycle timing. I.e., internally it's a behavioral
    > > model that has no timing or delays and probably doesn't describe the
    > > actual internal organization. But you should be able to compare its
    > > interface behavior with the real RTL model and they should match.
    > >
    > > -cb
    > >
    > >

    >
    > snipping
    >
    > True, there were once half a dozen C companies showing their wares at
    > DAC, don't think any survived. On John Cooleys website you can find
    > some old anti C discussion. Most VLSI guys detest the thought of using
    > C but as I said if you can live with the severe limits its not so bad
    > for single clock small hierarchy etc. Wouldn't want to force it on
    > anyone and its not easy to persude people to use something faster but
    > is also not easy to use.
    >
    > My ideal solution would be a V compiler that is mostly C even a little
    > C++ but with some verilog syntax & semantics added to it to make it
    > possible to write RTL Verilog that but has cycle C perf but is also
    > synthesieable. It might not have any event model to start.
    >
    > SystemVerilog does it the other way round and isn't done yet either.
    > Too big for my tastes.
    >
    > regards
    >
    > johnjakson_usa_com


    // ==================================================== //

    Wow, that was a pretty intense explanation, thanks for taking out the time.
    I think you're right about the ideal solution. I'd always previously
    believed
    that at least certain things ought to be unified, like the '{' & '}' instead
    of the
    "begin" & "end", (concatenation could be represented some other way), and
    the switch/case instead of the case/(state list). Then there's the
    "#define"
    instead of the " `define". Seems like if the designers of verilog really
    wanted
    it to look like C, they could have done a better job. I also wish they
    could
    roll back assembly and make it look more like C - to this day I still write
    assembly programs and catch myself using "//" for comments. Sheesh.

    But since a lot of tools I use don't always have the latest options, I just
    code
    in Verilog to be safe. I don't even code in Verilog2001, yet. It's not
    just
    because I'm an old fart, I just want my code to be compatible with any tool,
    any foundry, etc.

    Best regards,
    BB
     
    Blackie Beard, Aug 18, 2004
    #11
  12. mohammed rafi

    Eric Delage Guest

    Are you talking about validation of your architecture (in terms of features
    and performances)? Then have a look to a SystemC environment and spend some
    time writing a proper model at the correct abstraction level. Otherwise go
    directly to a HDL environment and don't lose your time developping in // a
    HDL and a SystemC models.

    I would recommend you to read "Writing Testbenches - Functional Verification
    of HDL Models" from Janick Bergeron. An expensive book but a very usefull
    one if you want to setup a good HDL verification methodology. I spent some
    time to set it up properly and I rapidly noticed some benefits in terms of
    productivity and efficiency.

    A verification plan? Take all your instructions one-by-one and write a few
    scenarios for each of them. Probably start w/ the MOVE ops, continue w/ the
    ALU ops and finish w/ the INTs. Progressively, as a number of instructions
    have been verified (and you are confident in them), you can use them to test
    the subsequent instructions. Confidence is the key.

    Verify your processor core in isolation. Don't play w/ any memory subsystem
    (cache, mmu, tlb, ...) at this level otherwise you'll mix so many problems
    that you won't know anymore what you're testing. For each instruction,
    reserve some testcases to simulate random responses from the memory
    subsystem to the processor core (random latency, fault ops, ...). The other
    testcase would use ideal responses.

    Eric

    mohammed rafi <> a écrit dans le message :
    ...
    > hi,
    >
    > i have not seen any message about verification posted in both
    > comp.lang.verilog and comp.lang.vhdl. i want to initiate a discussion
    > about verification.
    > can you pepole tell me how to verify a generic microprocessor. if you
    > give me the verification plan, testplan and the list of corner cases
    > it will be very useful.
    >
    > cheers,
    > m. rafi
     
    Eric Delage, Aug 20, 2004
    #12
  13. mohammed rafi

    Andy Freeman Guest

    (john jakson) wrote in message news:<>...
    > Most VLSI guys detest the thought of using
    > C but as I said if you can live with the severe limits its not so bad
    > for single clock small hierarchy etc. Wouldn't want to force it on
    > anyone and its not easy to persude people to use something faster but
    > is also not easy to use.


    Actually, there's a reasonable subset of C++ that can be automatically
    translated into synthesizable Verilog such that one can make useful
    equivalence guarantees between the behavior of the C++ and the
    Verilog.

    Said subset is not restricted to a single clock and or small
    hierarchies.
    Heck, it even works for latches as well as flip-flops.

    You want to augment it with an "other widths" arithmetic package (some
    applications depend on arithmetic widths other than 8, 16, 32, and 64)
    that also propagates unknowns correctly.

    Interestingly enough, this C++ subset works exactly the way that said
    "VLSI guys" describe hardware. The basic structure of designes in
    this
    C++ subset is a textual representation of what said VLSI guys draw
    when
    they're architecting or trying to figure out what's going on. It just
    doesn't look like the Verilog that they're used to writing.

    Yes, the Verilog that they insist on using for implementation is
    different
    from how they actually think and C++ can be closer. FWIW, it's much
    easier
    to teach folks to how to use this C++ subset to design hardware than
    it
    is to teach them how to use Verilog.

    Summit Design's FastC is along the same lines except that it's a
    SystemC
    subset which is very similar to this C++ subset.

    Note that there's an interesting business problem with using a C++
    subset
    to design hardware. The only things that the relevant EDA company can
    sell
    are:
    (1) the "other widths and unknowns" arithmetic library
    (2) a style checker (is the design in the C++ subset)
    (3) a C++ subset to Verilog compiler

    (1) isn't big enough to make money on. (2) and (3) are so fast that a
    hundreds of designers can share a single license.

    How do you price (2) and (3) so that you can sell to both Cisco and
    small shops AND make enough money to support development?

    > (Chris Briggs) wrote in message news:<>...
    > > Well, there was a startup 4-5 years ago called C-Level Design that
    > > promoted a C-based design style called "Cycle C." They claimed
    > > incredible simulation speedups based on it and they had a tool to
    > > convert it to synthesizable Verilog RTL. Apparently either it didn't
    > > work too well or they couldn't convince anyone that it did, because if
    > > memory serves the company basically ran out of money and was acquired
    > > by Synopsys for a song.


    C-Lev's problem was that they didn't actually understand what they
    were
    doing.

    Cycle C came from a project for Hitachi Semiconductor, America that
    C-Level
    flailed on. (Some HSA folks had been using the methodology to design
    hardware and hired C-Level to build some tools to support it.)
    C-Level
    didn't understand the differences between what they'd been doing and
    what HSA wanted/had been using.

    C-Level could have pulled it out because HSA reorg'd and the relevant
    HSA folk became available, but said misunderstandings persisted so the
    ex HSA-folk went it alone.

    They couldn't get funding on their own (in part because C-Level was
    sucking up the "design in C" mind share), C-Level didn't have a
    coherent
    product and soon both were broke and went off to to something else.
    And, C-Level's failures convinced everyone that "design in C" can't
    work even though all it actually proved was that there are C-based
    design tools that don't work.

    How do I know? I was one of the HSA folk. After I left HSA, I wrote
    a prototype of the C++ subset to synthesizable Verilog compiler. (It
    was a production-quality back-end/code generator, but my parser was a
    hack.)

    I'm doing something else these days.

    -andy
     
    Andy Freeman, Aug 21, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Geno

    Discussion

    Geno, Jul 18, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    524
  2. ALuPin

    Discussion "Async Reset"

    ALuPin, Oct 25, 2004, in forum: VHDL
    Replies:
    2
    Views:
    664
    Raghavendra
    Oct 27, 2004
  3. charles

    Re: Discussion Forum Application

    charles, Aug 25, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    391
    Nedu N
    Aug 25, 2003
  4. vasss_n
    Replies:
    1
    Views:
    950
    Krissy
    Aug 26, 2003
  5. Smithers
    Replies:
    3
    Views:
    357
    Scott Allen
    Jul 23, 2004
Loading...

Share This Page