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

[Klaus Rudolph]

Hi Onno,

thanks for your work. As also written in other mails today: I am really 
busy at the moment.
So please give me a few days (maybe more :-( ) to look inside your patch.

I have no experience with verilog and tools around. So it looks that 
checking your work and
try the results is a big amount of work.

So my idea is:
First I will check what you have changed and try to find out that 
nothing is broken with simulavrxx
next is to check the functionality, I think I can learn a lot of the 
verilog tools which is also nice but time consuming :-)

Can you give me a hint where to start and which tools I could/should use 
(geda suite?)


> BTW, I have another couple of questions regarding the simulavr code/wishlist:
>
> - Why are no exceptions used?
>  
I have no need for them :-)

> - Why are (const) char* used all over the place when there is std::string?
>  
Sometimes std::string needs a lot more time. The objects are dynamic and 
have a bit runtime overhead.
const char is simply a bit memory :-)

> - Wouldn't it be a good idea to separate the device configurations (at4433.*, 
> at8515.*, ...) into a separate configuration setting, maybe even one which is 
> automatically generated from the offical ATMEL docs with a little script? 
>  
Yes and No!
If all the hardware is highly abstracted, so that the bits in the 
registers could be defined from the header/config
files. But actually the register contents is coded manually and to catch 
some bits from the registers via dynamic configurations
at runtime is time consuming. So I have decided to do the work manually. 
Look into the hardware timer part. A lot of configurations
are possible. So a mega128 and mega16 differ a lot in using bits in 
timer related registers. And maybe I have not found a good
style to code a "generic" register description. Maybe templates could do 
the job, but I have not spend any time for that question
until now. I wrote the simulavrxx for my needs and my needs are 
fullfilled :-). Maybe you could add some knowledge on
make it more generic.


Thanks for your work!

regards
Klaus