exploring architectures

[Mark Wood-Patrick]

I'm starting to look at chisel and was wondering if anyone had thoughts on:

1. The best ways to explore architectural designs and verifying high level (fast but none cycle/transaction accurate models match more detailed models)
   
2. Use of tools like cucumber/scala test with chisel to define executable specifications for a design
3. A Roadmap of where folks think chisel is going over the next year or so would also be very useful

Mark

[Jonathan Bachrach]

On Fri, Feb 28, 2014 at 12:17 PM, Mark Wood-Patrick <mwoodp...@gmail.com> wrote:

I'm starting to look at chisel and was wondering if anyone had thoughts on:

1. The best ways to explore architectural designs and verifying high level (fast but none cycle/transaction accurate models match more detailed models)
   

we're working hard on a series of techniques for this.  we are making available a parameterization system and a design space exploration mechanism.  we're also making a bunch of simulation/emulation options for fast time and power evaluation including fpga support, a systemc backend, etc.

1. Use of tools like cucumber/scala test with chisel to define executable specifications for a design

you should look at our new Tester for a test harness to write tests in and the way we hook that into Scala's sbt test infrastructure.  we do this in src/test/scala in chisel repo.  you can run this with 

  sbt test

we are trying to add to this to get more complete coverage.

1. A Roadmap of where folks think chisel is going over the next year or so would also be very useful

here are some of our goals.  currently we've got a strong set of active grad and undergrad students contributing to chisel as well as some early adopters that contribute with pull requests.  informal near future plans are to 

o produce an properly documented and supported IR that all backends will be written in terms of.  this will make it easier for developers to write their own backends and transformational passes.

o build out a more advanced standard library layer and to produce an cookbook for advanced users

o better organize docs and website

o do another big bug fix push to drastically reduce outstanding bugs

Other features we're planning in the near future are:

o counter generation support

o snapshotting support

o fast power modeling on fpga's

o first class parameter support

o automatic design space exploration tool called jackhammer

o NOC and SOC generators

o support for FPGA application development especially on Xilinx Zynq

o tagged unions

o zero width wires

o visualization support

 

Mark

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To post to this group, send email to chisel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/1bf49650-1319-4c27-8b6c-6372cb0a793d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mark Wood-Patrick]

Some followup questions below

On Saturday, March 1, 2014 7:59:42 AM UTC-8, Jonathan Bachrach wrote:
On Fri, Feb 28, 2014 at 12:17 PM, Mark Wood-Patrick <mwoodp...@gmail.com> wrote:
I'm starting to look at chisel and was wondering if anyone had thoughts on:

1. The best ways to explore architectural designs and verifying high level (fast but none cycle/transaction accurate models match more detailed models)

we're working hard on a series of techniques for this.  we are making available a parameterization system and a design space exploration mechanism.  we're also making a bunch of simulation/emulation options for fast time and power evaluation including fpga support, a systemc backend, etc.

Any more details on this 

1. Use of tools like cucumber/scala test with chisel to define executable specifications for a design

you should look at our new Tester for a test harness to write tests in and the way we hook that into Scala's sbt test infrastructure.  we do this in src/test/scala in chisel repo.  you can run this with 
  sbt test

I will give that a try

 

we are trying to add to this to get more complete coverage.

1. A Roadmap of where folks think chisel is going over the next year or so would also be very useful

here are some of our goals.  currently we've got a strong set of active grad and undergrad students contributing to chisel as well as some early adopters that contribute with pull requests.  informal near future plans are to 
o produce an properly documented and supported IR that all backends will be written in terms of.  this will make it easier for developers to write their own backends and transformational passes.
o build out a more advanced standard library layer and to produce an cookbook for advanced users
o better organize docs and website
o do another big bug fix push to drastically reduce outstanding bugs
Other features we're planning in the near future are:
o counter generation support
o snapshotting support
o fast power modeling on fpga's
o first class parameter support
o automatic design space exploration tool called jackhammer
o NOC and SOC generators
o support for FPGA application development especially on Xilinx Zynq
o tagged unions
o zero width wires
o visualization support

Any more details on this or planned dates for initial support 

[Alexander Samoilov]

Hello Mark!

Nice  to see you in this group!

I played with Chisel a bit - implemented some cache related algorithms and cache simulator prototype.

The choice of Scala language for the host language of the Chisel DSL is an interesting and pleasant for me solution.

Scala is a very elegant and expressive language.

I found the tool very interesting and promising though still difficult to use due to hard to pin error messages.

As Chisel is a DSL embedded in Scala error messages after interpretation of the internal representation

used to be vague and imprecise.

But situation is getting better and recently there were significant improvements in Chisel.

Speaking about exploring architecture designs I think it would be nice to have a library of building blocks for it.

Chisel already have some building blocks for it.

There are a few use-cases of processor simulators built with the help of Chisel, say

1. Sodor 

https://github.com/ucb-bar/riscv-sodor

2. patmos

https://github.com/t-crest/patmos

Alexander (your colleague)

[Rupert Smith]

On Friday, February 28, 2014 8:17:58 PM UTC, Mark Wood-Patrick wrote:

I'm starting to look at chisel and was wondering if anyone had thoughts on:

1. The best ways to explore architectural designs and verifying high level (fast but none cycle/transaction accurate models match more detailed models)
   

I started out using a project called spin to do some design space exploration:

http://toem.de/index.php/projects/spin

Not convinced its a great tool for doing this, but you might like to take a look and decide for yourself.

 

2. Use of tools like cucumber/scala test with chisel to define executable specifications for a design

I've tried scalatest and scalacheck with chisel and found them to be quite useful. In particular I used scalacheck to either exhaustively test all input/output combinations on small circuits where this is feasable, or to drive randomized testing where it is less so. I didn't get quite so into the 'behavioural driven' testing and executable specifications side of things, because as far as I can see this simply amounts to getting your test cases to also print out text to the console that claims that the test fits a specification. Despite that, I do quite like the readable test report it generates.

scalacheck could be a little frustrating in the way it generated randomized test cases. You can produce random vectors, and a guard condition that verifies that a random vector is a suitable input for a test. If your guard conditions fail too many tests, the whole test fails. I can't remember the details but I did have to work around this and some other shortcomings of this test framework. On the whole, I think it was worth it.

Rupert

[Jonathan Bachrach]

On Mon, Mar 3, 2014 at 12:46 PM, Mark Wood-Patrick <mwoodp...@gmail.com> wrote:

Some followup questions below

On Saturday, March 1, 2014 7:59:42 AM UTC-8, Jonathan Bachrach wrote:

On Fri, Feb 28, 2014 at 12:17 PM, Mark Wood-Patrick <mwoodp...@gmail.com> wrote:
I'm starting to look at chisel and was wondering if anyone had thoughts on:

1. The best ways to explore architectural designs and verifying high level (fast but none cycle/transaction accurate models match more detailed models)

we're working hard on a series of techniques for this.  we are making available a parameterization system and a design space exploration mechanism.  we're also making a bunch of simulation/emulation options for fast time and power evaluation including fpga support, a systemc backend, etc.

Any more details on this 

there is a version of the parameterization system in master now.  i will get author to write up docs.  the sim/emu/modeling work will produce results hopefully by june. 

1. Use of tools like cucumber/scala test with chisel to define executable specifications for a design

you should look at our new Tester for a test harness to write tests in and the way we hook that into Scala's sbt test infrastructure.  we do this in src/test/scala in chisel repo.  you can run this with 
  sbt test

I will give that a try

 

we are trying to add to this to get more complete coverage.

1. A Roadmap of where folks think chisel is going over the next year or so would also be very useful

here are some of our goals.  currently we've got a strong set of active grad and undergrad students contributing to chisel as well as some early adopters that contribute with pull requests.  informal near future plans are to 
o produce an properly documented and supported IR that all backends will be written in terms of.  this will make it easier for developers to write their own backends and transformational passes.
o build out a more advanced standard library layer and to produce an cookbook for advanced users
o better organize docs and website
o do another big bug fix push to drastically reduce outstanding bugs
Other features we're planning in the near future are:
o counter generation support
o snapshotting support
o fast power modeling on fpga's
o first class parameter support
o automatic design space exploration tool called jackhammer
o NOC and SOC generators
o support for FPGA application development especially on Xilinx Zynq
o tagged unions
o zero width wires
o visualization support

Any more details on this or planned dates for initial support 

we're trying to do the big bug fix push, doc reorg, and stdlib / cookbook with a month or so.

the other work is targeted for end of semester -- june timeframe.

 

 

Mark

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To post to this group, send email to chisel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/1bf49650-1319-4c27-8b6c-6372cb0a793d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To post to this group, send email to chisel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/09475f73-5457-43e6-8cd3-4ff12878d0b4%40googlegroups.com.

[Rupert Smith]

On Friday, February 28, 2014 8:17:58 PM UTC, Mark Wood-Patrick wrote:

Use of tools like cucumber/scala test with chisel to define executable specifications for a design.

 My scalatest/scalacheck code can be found here:

https://github.com/rupertlssmith/numbers/tree/master/numbers_chisel/src/unittests/scala/com/thesett/numbers/chisel/impl/translator/rx

Rupert

[Rupert Smith]

On Friday, February 28, 2014 8:17:58 PM UTC, Mark Wood-Patrick wrote:

The best ways to explore architectural designs and verifying high level (fast but none cycle/transaction accurate models match more detailed models).

I had to remove the spin stuff from my code before putting it up on GitHub, as spin is not open source. PM me if you want a copy of that, you will be welcome to have it.

Rupert 

[Rupert Smith]

Something else you may find interesting in this regard, are the software only version of my tests:

https://github.com/rupertlssmith/numbers/tree/master/numbers_api/src/main/com/thesett/numbers/test/stack

I defined an API to interact with the communication protocol parser that I was creating. Then I implemented a 'test stack' that drives test cases through the API. I implemented a first cut in Java, software only. The software implementation in this case was very trivial, but it enabled me to prove that the test stack was working correctly, and to begin to get an initial feel for the design.

I then implemented a version in spin, and added the necessary hooks for the test stack.

I then implemented a version in chisel, and also ran that through the test stack. The chisel implementation being the lowest level one, took the most work to complete. In addition to the functional testing provided by the test stack, I wrote unit tests for each chisel module to drive their design and satisfy myself of their correctness.

So there you have it, one way of working down from a high level design and applying a fairly rigorous test driven approach to the work.

Rupert