a discussion about verification

[mohammed rafi]

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

 

[Ralf Hildebrandt]

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

 

[Jim Wu]

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 (jimwu88NOOOSPAM@yahoo.com remove NOOOSPAM)
http://www.geocities.com/jimwu88/chips

 

[Blackie Beard]

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" <m_mohammedrafi@yahoo.com> wrote in message
news:977f64b1.0408132104.29346160@posting.google.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

 

[john jakson]

m_mohammedrafi@yahoo.com (mohammed rafi) wrote in message news:<977f64b1.0408132104.29346160@posting.google.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

 

[Blackie Beard]

Can you give me link to familiarize myself with "cycle c"?
Never heard of it before.

Regards,
BB

"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408150633.58edd691@posting.google.com...

m_mohammedrafi@yahoo.com (mohammed rafi) wrote in message
news:<977f64b1.0408132104.29346160@posting.google.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

 

[john jakson]

"Blackie Beard" <bb@fearlessimmortalwretch.com> 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" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408150633.58edd691@posting.google.com...
m_mohammedrafi@yahoo.com (mohammed rafi) wrote in message
news:<977f64b1.0408132104.29346160@posting.google.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

 

[Chris Briggs]

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" <bb@fearlessimmortalwretch.com> 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" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408150633.58edd691@posting.google.com...
m_mohammedrafi@yahoo.com (mohammed rafi) wrote in message
news:<977f64b1.0408132104.29346160@posting.google.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

 

[Chris Briggs]

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" <bb@fearlessimmortalwretch.com> 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" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408150633.58edd691@posting.google.com...
m_mohammedrafi@yahoo.com (mohammed rafi) wrote in message
news:<977f64b1.0408132104.29346160@posting.google.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

 

[john jakson]

chris@engim.com (Chris Briggs) wrote in message news:<f8e87dac.0408170631.667c7617@posting.google.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

 

[Blackie Beard]

"john jakson" <johnjakson@yahoo.com> wrote in message
news:adb3971c.0408171631.3e92d4d5@posting.google.com...

chris@engim.com (Chris Briggs) wrote in message
news:<f8e87dac.0408170631.667c7617@posting.google.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

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

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

 

[Eric Delage]

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 <m_mohammedrafi@yahoo.com> a écrit dans le message :
977f64b1.0408132104.29346160@posting.google.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

 

[Andy Freeman]

johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0408171631.3e92d4d5@posting.google.com>...

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@engim.com (Chris Briggs) wrote in message news:<f8e87dac.0408170631.667c7617@posting.google.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.

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

 

On Saturday, August 14, 2004 at 9:02:02 AM UTC+3, mohammed rafi wrote:

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

When it comes to reading code from an assembler/compiler into vhdl/verilog code this phttp://bknpk.ddns.net/my_web/cpu_8051_ver/assembly_howto.htmlage can be of some use: