Re: [Simulavr-devel] Patch: simulavrxx <->Verilog binding

[Onno Kortmann]

Hi Klaus,
> After that I have a line in a hand crafted Makefile like this:
>
> iverilog-vpi  --name=avr $(OBJECTS) $(BFDOBJECTS) vpi.o -lc -lm
>
> where the OBJECTS the same as for other targets in the project like for
> simulavr.
> BFDOBJECTS is simply the list of all *.o files in my local tmp directory
> where I un-archived the libbfd/libiberty.
Ok, that's probably a better thing to do, I just did not run into any 
problems and so got caught in a local minimum solution ;-)
As you seem to use the savannah patch system, I'll try to use it and place my 
patches there.
I have now posted a patch there which simply reimplements the functionality of 
the iverilog-vpi script. I hope this one is working and ok for you. I use your 
path for the libbfd, and according to the 'ld' man page, this *should* 
work...


> But what I see in the gtkwave makes no sense for me.... ???
> The output for portb/pinb is 01/00/02/00/04 and so on.... this has no
> relation the the program, or? :-)
Well, I hope the program and everything is right (well, no, there is at least 
something dirty in loop.c, it should be DDRB=0xff and not DDRB=1, but that is 
ignored by the verilog side so far - it still works but is confusing, maybe 
you should change that before commit..... (it is in the posted patch) :-). 

> Could you explain that for me please... :-)
Sure, I think a short walkthrough is also helpful as a reference... So:

The small program loop.c simply reads from PINB and writes to PORTB 
repeatedly, after initializing PORTB with 0000 0001 once. That's all.

The verilog side is also rather easy, one has to take a look at loop.v, which 
is the file with the top-level module 'test ('the "-s test" argument in the 
Makefile defines this). There, some wiring is declared with

*** wire clk;
*** wire [7:0] portb;
*** wire [7:0] pinb;

for the clock and the two ports.

The portb and pinb wires are simply connected together statically 
(a 'continous assignment') using 

*** assign pinb=portb;

That's all the environment declared by the verilog code, as I think an example 
(and test) should be simple. This could be replaced with much connections to 
other components (for example and AVR talking to a PIC with a VPI interface, 
whatever one can imagine :-))) and much more logic.

Verilog knows where the data comes from and goes to here, so nothing else has 
to be declared.

The lines

*** defparam  avr.progfile="loop";
*** AT90S4433 avr(clk, portb, pinb);
*** avr_clock clock(clk);

instantiate the components of the circuit, a AT90S4433 and a clock oscillator 
driving the AVR (the clk variable is given to the components and is therefore 
connected together). 

Both components are defined in terms of the simulavrxx exported functions in 
avr.v. As said, this part is still somewhat incomplete, for example a2v and 
v2a do not translate all 'signal levels' between simulavrxx and verilog yet. 
Verilog builds components out of components ('module's) and that leads 
naturally to this schematic-like hierachical design format.

Overall, the whole setup is simply an AVR that reads back its own output pins, 
boring, not exactly realistic (as this would happen already in the AVR), but 
it works. Between each read/write of the portb/pinb lines, a shift is made 
which produces this staircase pattern with a wandering bit (to see it, select 
portb/pinb and press F3 to extend it to single bit lines). The whole thing 
should be as cycle-accurate as your simulator, but maybe you could take a 
look at the call of your Step function and if I used it the right way?
Also, I think you should take another overall look at the vpi.cpp file and 
think whether I took the right pieces to export. I think the interface is 
clearest now, but you as the creator may have other ideas about a sane 
interface to your code... :-)

> So what should we do to get the things play:
> Please find out how to link against the correct libbfd/libiberty. If not
> possible (I have searched arround 2 hours :-( )
> bring the tmp-object-dir to the build-system. I am not an expert of
> autotools at all. But I hope that there is a trick
> in the varilog commands to link against correct libs. Attention: there
> is no libbfd.so in the standard avr-compilation. Maybe there
> is a trick how to get them and this should be documented.
> After that I will verify the build-toolchain and check your changes in.

> And yes: could you send a smart documentation how to use the simulavrxx
> into verilog for beginners (like me:-)
Sure, I can do that. Is something which only touches simple cases such as the 
description above enough, or do you like to have more complex examples? I 
hope that for now the above description should get you going, but sure a good 
description won't hurt :-) I'll add it in the patch system, as soon as I have 
written the stuff. The patch is also not tested with thousands of tests on my 
side, so maybe I'll correct my patch someday and repost it. If that is too 
much of a hassle for you (and you distrust my invention too much ;-), it may 
be a better to wait a bit before bringing this into cvs head, so others can 
test and play with it.

> And another question: Is it possible to attatch gdb while runnung
> verilog and have online graphs and maybe able to stimulate
> pins from a tool inside the verlilog... as you can see: I have no idea
> what verilog can do for us! :-)
Well, I thought about the triple interaction with gdb+simulavrxx+verilog, but 
my brain is not yet clear about the interaction (one would surely need some 
intelligent threading somewhere, so that no task blocks the other task). 

I have written the VPI interface to be able to test my AVR projects including 
their surroundings. For example to test my software implementation of an 
RS232 transceiver with jitter, error bursts etc. for reliability. 

I think it should help to include it in the documentation examples, it's only 
a few 100 lines of code.

Another thing which I plan to do with it (not yet finished) is to remove some 
minor bugs in my somewhat bloated implementation of an DCC model railroad 
booster+controller, implemented in two separate AVRs (1200 for the control of 
the power components, and 4414 for the DCC signal generation and top-level 
control). That things already exists as hardware, but its much harder to 
debug deterministic logic problems with a scope than with a virtual logic 
analyzer :-) Now, with the interface, that should be easily possible...: An 
AVR instance for the 1200, one for the 4414, and some glue logic and a 
high-level approximate simulation of the analog parts in verilog. I do not 
think that such a big project belongs into an 'examples' folder, though :-) 

> Where could I start reading in using verilog? :-)
A colleague from work introduced me to verilog, but I think the tutorial 
linked from Wikipedia is good and complete enough to get one going.

Greetings,

Onno