alvieboy

Plans for the future

Recommended Posts

Just to let you know plans for the near future:

* Arduino IDE 1.0 is almost merged in, so we'll stay in sync with arduino releases. I'll be expecting the "One" release perhaps in Q2 2012, and that will pose a significant "threat" to ZPUino, for it uses a 32-bit ARM processor. Let's see how it goes. Good news is it will also feature a new IDE, hopefully in QT, so we get rid of Java overhead.

* The Extreme core is finally taking shape (http://zpuino.blogspot.com/2011/12/new-extreme-core.html), and preliminary synthesis for S3E250 shows we can go up a bit more, and for S6 (-4, the slower one) we might even be able to get to 133MHz.

I'm still expecting Arduino 1.0 IDE to come out. I won't release before that, because I still have to run a bunch of tests.

Other note about Extreme core: it will draw much *less* power. And it will be much more versatile, even allowing slower RAM (SRAM, SDRAM, so on). Eventually I might merge some icache/dcache stuff I wrote some time ago, which would allow to run directly from SPI flash (but of course, with many cache misses).

Stay tuned :)

Best,

Álvaro

Share this post


Link to post
Share on other sites

This is very exciting news, drawing less power will be a nice benefit. :)

I didn't realize they were thinking of changing from Java to something else for the Arduino 1.0 software.

The ZPUino will still be quite a bit more flexible then the ARM Arduino board will be, the challenge is making it easy and flexible so people adopt it. I really think having some kind of a debugger would be very appealing.

Jack.

Share this post


Link to post
Share on other sites

There's something I forgot to mention regarding Extreme core.

My main motivation for speeding up Extreme release it's not its performance. The two main reasons are power consumption (btw, it's running right now on S6LX4 [papilio_plus] for 2 hours, and board is pretty chill), and most important - it's design allows for a DMA engine, and for external memory (eventually even caches) thus reducing the dependency on the block ram for data and code.

It's still however a bit large for my likings - but with this complex design (it has a 3-stage pipeline) we can't do much more. Also max speed is being limited right now by the DSP48 multipliers on S6LX4.

It's still running at 100MHz on Plus, but I'd wanted it up to 133 :P

Álvaro

Share this post


Link to post
Share on other sites

Ah, and debugger:

It's now possible to debug the thingie with JTAG. :) Actually that was the only means I had to find a nasty bug earlier during development.

The debug interface is now able to reset, freeze and do single-stepping, and extract all relevant information from it. Still missing is code injection, so that we can access IO and memory. Debugging with interrupts enabled is also still not planned, I've to think about it for a while.

Álvaro

Share this post


Link to post
Share on other sites

Yes! The debugger has me the most excited. :) The only reason I can think of to use the Microblaze solution over something like the AVR8 or the ZPUino has been the integrated debugger. If your ZPUino Extreme is going to support debugging then that is a slam dunk. :)

The running for two hours at 100Mhz and still being chill is very, very cool and pretty amazing actually.

BTW, I never got a chance to say congratulations on your 7400 Contest entry, getting second place in the whole competition is quite a feat.

Jack.

Share this post


Link to post
Share on other sites

Yes! The debugger has me the most excited. :) The only reason I can think of to use the Microblaze solution over something like the AVR8 or the ZPUino has been the integrated debugger. If your ZPUino Extreme is going to support debugging then that is a slam dunk. :)

The next debugging step will be hard though, because this is a pipelined design. Let's see how it goes.

The running for two hours at 100Mhz and still being chill is very, very cool and pretty amazing actually.

Main reason is we are not driving the whole memory at once (like old cores do). So only a small BRAM has a very high use (the stack).

BTW, I never got a chance to say congratulations on your 7400 Contest entry, getting second place in the whole competition is quite a feat.

Thanks! That was quite fun and stressing. The last IC needed arrived one day before the deadline - and I was not even sure the whole design would work. It did, that was the most amazing thing!

Alvie

Jack.

Share this post


Link to post
Share on other sites

Just to let you know that I stated integrating the debug features with OpenOCD.

Now, complex would be to connect it to Arduino IDE.

Eventually Eclipse would be easier, but I don't like it very much.

Share this post


Link to post
Share on other sites

Excellent! We've been kicking around the idea of figuring out how to disable the FPGA and expose the FT2232 chip as an OpenOCD jtag programmer/debugger.

Are you envisioning the use of an external OpenOCD debug device or using the FT2232 with a bscan primitive or something?

I was just thinking along the lines of making a shield for the Papilio Logic device that asserts the FPGA reset line and then routes the JTAG lines to a variety of JTAG header form factors.

Jack.

Share this post


Link to post
Share on other sites

Using BSCAN primitives have a few drawbacks:

a) You cannot chain devices.

B) S3E BSCAN is quite ugly (S6 is more OK, but still some issues)

c) Needs specialized software on debugger (complex, I may say).

I have a full TAP implementation running, so I don't need BSCAN at all. Would be nice to be able to wire them (the real JTAG pins) into FPGA. But that is hard (not enough pins).

FT2232 JTAG devices are very common these days. I wonder if you can give some added value with Papilio.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now