PLI model vs. Verilog model 
Author Message
 PLI model vs. Verilog model

Quote:

>I have done designs using Verilog, and I am about to
>get a model of a CPU done in C to be linked via PLI.
>Not being very familar with this process, I would like
>to find out if there are any limitations in this
>C model of a CPU compared to a model done in Verilog.

The only limitation (assuming that the model functionally performs as
advertised), it that you will have no access to the core functionality
of the processor implementation, eg. you can't scope into the ALU and see
how its implemented in HDL or gates. Hopefully the model developer added
losts of useful debug capability to trace dump the core, reverse assemble
code, possibly throw up an X window to view the runtime state fo the
core as you single step instructions, etc.

Good stuff, to bad you won't be able to synthesize the core from the PLI
object...

Regards,
Mark
--

/* College of Engineering    Department of Computer Engineering & Science */
/* Florida Atlantic University                                            */
/* 777 Glades Road                          Boca Raton, FL 33431-0991 USA */



Sun, 12 Apr 1998 03:00:00 GMT  
 PLI model vs. Verilog model

Quote:
> I have done designs using Verilog, and I am about to
> get a model of a CPU done in C to be linked via PLI.
> Not being very familar with this process, I would like
> to find out if there are any limitations in this
> C model of a CPU compared to a model done in Verilog.

No real limitations, although some things you have to watch out for:

1) The C model ( in most likelyhood ) has no timing associated with it,
no bus interface, and probably models the system internally. You will need
to spend time coming up with two interfaces: a) the PLI interface between
the C and the Verilog language domain and b) the interface between your
Verilog bus shell and the rest of the system. Expect to tinker with the
C model quite a bit to remove internal system references and have them
go through the PLI interface. If you're lucky or the model was written
with this application in mind, you won't have to restructure too badly. You
should expect lots of state machines ( as opposed to function calls ) in
the resulting code.

2) While you're gaining in the processor department, you still need to
verify the bus interface somehow. I've written virtual processor models
before ( VAX and SPARC ) and the bus interface takes at least as long as
the processor core.

3) Unless you're confident that the C model is not going to need lots of
rework to get it structured so that it can suspend while waiting for a
piece of data that you need to get through verilog simulation - my advice
is to write your own core model in Verilog and use the C model as a reference.
It's much easier to suspend processes in verilog than it is in C.

4) Something I haven't tried and am not sure works is lightweight threads
in PLI. These tend to be very machine specific, which may or may not matter.
This would require little restructuring.

5) You could use Sockets, which work alot like a file system. There can be
a pretty sizable performance hit, because you're doing full context
switching, plus the socket overhead.

My favorite approach is to model the processor in Verilog, partly because
it's fun ( and tends to go very quickly as a result ), and partly because
it allows me to add things to the processor that you normally wouldn't
find, like extra traps, address space, architectural parameters, etc.
On the SPARC model I wrote, I had completely programmable bus behavior,
that is, I could mimic anything on that bus, including multiple devices.
This was done through traps, so that test code could be run in the lab
as well.

If you absolutely have to use the C model, I would probably try the
lightweight threads approach first, as it has a good compromise between
model restructuring and performance, provided it works. If you need to
support more than one machine, think about putting it in a library you
can change from machine to machine.

Of course, it's hard to tell when I haven't seen the model - so some of
my generalizations may be off . . .

                                        John Williams



Tue, 14 Apr 1998 03:00:00 GMT  
 PLI model vs. Verilog model
Quote:
>    The model like that is exactly what our designers want for debugging
>digital design. Does it possible to find one for PowerPC series?
>    Why CPU deisgners didn't use source protection capability of Verilog?
>I think the reason may be speed advantage of C before Verilog not
>security, because it is possible to write Verilog model that hides
>gate implementation.

Dmitry,

I believe there is a PowerPC PLI model available; I'm not sure what core(s)
or how complete they are in terms of bus timing - maybe someone from
Somerset (PowerPC) design center will reply...

Regards,
Mark

--

/* College of Engineering    Department of Computer Engineering & Science */
/* Florida Atlantic University                                            */
/* 777 Glades Road                          Boca Raton, FL 33431-0991 USA */



Wed, 15 Apr 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. c model convert to verilog/VHDl model

2. How to model the transmission gate in Verilog without using tran (Behaviour model)

3. Object models, Domain models, Application models, and MVC?

4. Object models, Domain models, Application models, and MVC?

5. setting the model of a TreePresenter in Dialog>>model:

6. Should ReferenceView<<model return referee model?

7. Data Modeling/Object Modeling (was Re: [OT] RE: help -- persuade my boss to adopt ruby)

8. Models Models?

9. I2C Model Synthesizable Model

10. C model in model tech.

11. MODEL: Need 68030 model.

12. a 3D model search engine, currently about 20,000 models indexed

 

 
Powered by phpBB® Forum Software