Support to set processor frequency at the <proc>.ac file

8 views
Skip to first unread message

Liana Duenha

unread,
Nov 22, 2016, 2:27:35 PM11/22/16
to archc-dev
Hey ArchC Team,

What is your opinion about including support to set processor frequency at the <proc>.ac file? 

Something like that (for MIPS):

ARCH_CTOR(mips) {

    ac_isa("mips_isa.ac");
    set_endian("big");
    set_proc_freq ("xxx_mhz") 

  };

We already have the aforementioned method at the ac_module class. 

void ac_module::set_proc_freq(unsigned int proc_freq_mhz) 

This method only set the clock period (in nanoseconds) doing 1000/proc_freq_mhz.


--
-------------------------------------------------------------------------
Liana Duenha

Faculdade de Computação - FACOM/UFMS
Website Institucional: www.facom.ufms.br


Faculty of Computing - FACOM/UFMS
Faculty Website: www.facom.ufms.br

Rafael Auler

unread,
Nov 22, 2016, 2:50:10 PM11/22/16
to ArchC Development
What is the intended usage for this information?
> --
> You received this message because you are subscribed to the Google Groups
> "ArchC Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to archc-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Liana Duenha

unread,
Nov 22, 2016, 3:33:26 PM11/22/16
to archc-dev
I think this is one of the main attributes of a processor if we are interested in 

DVFS studies
Performance evaluation
Processor Optimizations
Timing Accuracy
Heterogeneous platforms
and so on...

In general, performance simulators like Multi2Sim and  Sniper allow setting the processor frequency at the platform configuration file. 

Setting "hard-coded" the module period is not the better way to do this, in my opinion.

> email to archc-dev+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "ArchC Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archc-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Rodolfo Azevedo

unread,
Nov 23, 2016, 8:10:08 AM11/23/16
to archc-dev
I would like to have a different approach here.

  Currently, we have two files that describes the hardware (resources) and the instructions. These are the two main ArchC files. Latter, these files get transformed into several .cpp files for simulation, compilers, etc.

  Whenever we need to change the cache configuration, we need to change the main resource file. The same will happen for frequency. I think that the best approach is to create a configuration file. Maybe mips-config.ac and move all those configurations there. Maybe even considering this configuration as the main ArchC file. Doing so, we could have several configurations with varying cache sizes, and frequencies, and so on. All of them pointing to the same resource and ISA files.

  But this will also have a drawback:

  For each new addendum to ArchC, new files are created, including some with fixed names. So you can create mips.ac, them you create mips-isa.ac and tell ArchC that you are using mips-isa.ac as the ISA. But you do not give such information to compilers, gdb, syscalls and other tools. You just include your file with the correct name and call the specific tool. It will find your file through a preset naming convention. 

  In this way, our goal should be to tie all files together. Currently we already have support for #include in ArchC. We could think about new files being added as organized contents without any restrictions from our point of view. We just provide best practices (like you should split your C code into .h and .c).

  Overall, I this is what I think:
  1) acsim and other tools should receive a configuration file. This configuration should be similar or even equal to the current mips.ac, sparc.ac, etc.
  2) It should be possible to create several configuration files by pointing them to the same resource/isa files
  3) No file should be required if not specified in the source code (we should not issue an error if the user did not provide gdb information but did not included this in any of our source codes).

    Rodolfo



-------------------------------------------------------------------------
Liana Duenha



Faculty of Computing - FACOM/UFMS
Faculty Website: www.facom.ufms.br

--
You received this message because you are subscribed to the Google Groups "ArchC Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archc-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Rodolfo Jardim de Azevedo
http://www.ic.unicamp.br/~rodolfo
IC - University of Campinas - UNICAMP

Liana Duenha

unread,
Nov 23, 2016, 2:20:46 PM11/23/16
to archc-dev
Hello Rodolfo,

Please correct me if I am wrong.

It means to provide a set of configuration files depending on the main goal of the simulator.

For example: 

  • resources and ISA configuration files (as we already have)
  • memory_config
  • cache_config
  • power_config
  • network_config (for platforms...)
  • etc

As we need them, we could specify these configuration files in the source code. 

I think we already have most of the information above spread across multiple files (at the ac_cache directories,  power libraries, ...). So we just need organizing them using some coding standard and placing them in a correct directory.

Do I see the problem in a very simplistic way??? 

Liana

-------------------------------------------------------------------------
Liana Duenha



Faculty of Computing - FACOM/UFMS
Faculty Website: www.facom.ufms.br

--
You received this message because you are subscribed to the Google Groups "ArchC Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archc-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Rodolfo Jardim de Azevedo
http://www.ic.unicamp.br/~rodolfo
IC - University of Campinas - UNICAMP

--
You received this message because you are subscribed to the Google Groups "ArchC Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archc-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
-------------------------------------------------------------------------
Liana Duenha

Faculdade de Computação - FACOM/UFMS
Website Institucional: www.facom.ufms.br

Rodolfo Azevedo

unread,
Nov 23, 2016, 5:10:46 PM11/23/16
to archc-dev
Hi Liana,

  I think that we should have one file with configurations and other files with descriptions. In this way, we do not need to edit the main model file to change both frequency, cache configurations, memory, power model input parameters, etc. Maybe we could use this file to even more configurations in the future.

  Rodolfo

-------------------------------------------------------------------------
Liana Duenha



Faculty of Computing - FACOM/UFMS
Faculty Website: www.facom.ufms.br

--
You received this message because you are subscribed to the Google Groups "ArchC Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archc-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sandro Rigo

unread,
Nov 24, 2016, 11:53:49 AM11/24/16
to arch...@googlegroups.com
I like the idea of one configuration file with multiple sections. Particularly, if we are going to add information regarding platforms, external memories, etc that does not fit quite well mixed in the processor resource description.


Prof. Sandro Rigo
Computer Systems Laboratory
IC-UNICAMP
http://www.ic.unicamp.br/~sandro

Liana Duenha

unread,
Nov 24, 2016, 1:05:18 PM11/24/16
to archc-dev
Yes! Ideas are getting better.

If I've understood correctly, description files are something like we already have: <proc>.ac, <proc_isa>.ac, and so on
So we need only create the configuration file with appropriate sections. 

Could you be more specific about the most appropriate syntax or language to the configuration file??? 







Reply all
Reply to author
Forward
0 new messages