Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > a discussion about verification

Reply
Thread Tools

a discussion about verification

 
 
mohammed rafi
Guest
Posts: n/a
 
      08-14-2004
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
 
Reply With Quote
 
 
 
 
Ralf Hildebrandt
Guest
Posts: n/a
 
      08-14-2004
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
 
Reply With Quote
 
 
 
 
Jim Wu
Guest
Posts: n/a
 
      08-14-2004
> 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.


You may want to post your question on Verification Guild
(http://verificationguild.com/).

HTH
Jim ((E-Mail Removed) remove NOOOSPAM)
http://www.geocities.com/jimwu88/chips
 
Reply With Quote
 
Blackie Beard
Guest
Posts: n/a
 
      08-15-2004
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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



 
Reply With Quote
 
john jakson
Guest
Posts: n/a
 
      08-15-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (mohammed rafi) wrote in message news:<(E-Mail Removed). com>...
> 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
 
Reply With Quote
 
Blackie Beard
Guest
Posts: n/a
 
      08-17-2004
Can you give me link to familiarize myself with "cycle c"?
Never heard of it before.

Regards,
BB

"john jakson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> (E-Mail Removed) (mohammed rafi) wrote in message

news:<(E-Mail Removed). com>...
> > 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



 
Reply With Quote
 
john jakson
Guest
Posts: n/a
 
      08-17-2004
"Blackie Beard" <(E-Mail Removed)> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > (E-Mail Removed) (mohammed rafi) wrote in message

> news:<(E-Mail Removed). com>...
> > > 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
 
Reply With Quote
 
Chris Briggs
Guest
Posts: n/a
 
      08-17-2004
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" <(E-Mail Removed)> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > (E-Mail Removed) (mohammed rafi) wrote in message

> news:<(E-Mail Removed). com>...
> > > 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

 
Reply With Quote
 
Chris Briggs
Guest
Posts: n/a
 
      08-17-2004
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" <(E-Mail Removed)> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > (E-Mail Removed) (mohammed rafi) wrote in message

> news:<(E-Mail Removed). com>...
> > > 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

 
Reply With Quote
 
john jakson
Guest
Posts: n/a
 
      08-18-2004
(E-Mail Removed) (Chris Briggs) wrote in message news:<(E-Mail Removed). com>...
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Good websites for Formal Verification ? thewhizkid VHDL 3 10-07-2003 03:04 PM
Resume: Design Verification Consultant (Specman) Veritec VHDL 2 09-26-2003 07:24 PM
Verification Intern Positions Available Recruit Interns VHDL 0 08-14-2003 09:56 PM
Re: Outsoursing Hardware verification Rajesh Bawa VHDL 2 08-05-2003 09:21 PM



Advertisments