brainstorm: new LPC dongle from Artec Group

[Martin-Éric Racine]

Greetings,

Noticing that the main community of users for Artec Group's LPC dongle
has been at Coreboot, I have two announcements to make:

1) The current LPC dongle model is EOL.  Some components no longer exist
on the market so, after the batch we're producing this month, it's gone.

2) We're already working on a new LPC dongle to replace the current one.

In conjunction with item #2 above, we are hereby giving the Coreboot
community an opportunity to influence the design of this new product.
While we cannot guarantee that every idea submitted will be used, we
will definitely be reading all the feedback we receive.

The end result will be an even better LPC dongle that serves the growing
needs of the embedded hardware developer community.

To compare with the current dongle design, see:

http://artecgroup.myshopify.com/products/programmable-lpc-dongle

Looking forward to receiving your ideas for this new LPC dongle product.

Best Regards,
-- 
Martin-Éric Racine
Business Development Manager
Artec Group OÜ

[Peter Stuge]

On Fri, Aug 08, 2008 at 02:15:39PM +0300, Martin-Éric Racine wrote:
> In conjunction with item #2 above, we are hereby giving the Coreboot
> community an opportunity to influence the design of this new product.

I have a few thoughts, in order of importance they are:


* By far the most important one: Use a more intelligent USB chip

USB can do 480Mbps so transfering half a megabyte should not need to
take several seconds. There is obviously a huge opportunity for
improvement here, and as it happens this is also the main bottleneck
in the dongle when doing intensive development.

The most elegant solution is to implement USB completely in the FPGA,
but a separate chip is likely more economical. Key point is that it
must not be a dumb serial chip.

Cypress had the EZ-USB SX2 (not FX2) but unfortunately it's EOL.

The PLX NET2270/NET2272 are really powerful, but may be a bit costly.

NEC µPD720122 is another option, it's on par with the Netchip.

NXP ISP1582 may be the winner. Unit price/2k is 2.87 USD.

Finally it's of course also possible to implement part of USB in the
FPGA and only use an external transceiver chip. There are plenty of
those chips available.


* Use an Actel FPGA that is live from power on

This allows the dongle to be powered comfortably from the target
without compromising usability.


* Automatic power switch with a few protection diodes

Get rid of the power switch jumper.


* Replace any other jumpers with toggle switches

Ideally remove hardware configuration completely and do all settings
via USB.


* SMD LEDs

Because the through hole ones often get bent out of shape when the
dongle is carried in a bag.


//Peter

[Stefan Reinauer]

Dear Martin-Éric,

we're using two of the dongles at coresystems; and they're in use many 
times every day. Thank you guys for creating this device. It almost 
completely replaced the Galep V here for non-SPI systems.

With parallel abuild, a compile+flash cycle for an 8MBit image takes 
about 30s, the dongle part takes about 25s of that time.

Peter Stuge wrote:
> On Fri, Aug 08, 2008 at 02:15:39PM +0300, Martin-Éric Racine wrote:
>   
>> In conjunction with item #2 above, we are hereby giving the Coreboot
>> community an opportunity to influence the design of this new product.
>>     
>
> I have a few thoughts, in order of importance they are:
>
>
> * By far the most important one: Use a more intelligent USB chip
>
> USB can do 480Mbps so transfering half a megabyte should not need to
> take several seconds. There is obviously a huge opportunity for
> improvement here, and as it happens this is also the main bottleneck
> in the dongle when doing intensive development.
>
> The most elegant solution is to implement USB completely in the FPGA,
> but a separate chip is likely more economical. Key point is that it
> must not be a dumb serial chip.
* Possibly, in connection with this, use SRAM or DRAM to store or cache 
the images transferred from the host side. I think writing the flash 
takes about as long as transferring it over serial port, so using a 
faster USB (network instead of serial) chip would only move the bottle neck.

* One habit of the dongle is very ugly; the need to reset it after 
loading it. I think it would be a good idea to have the dongle reset 
itself (or, the lpc part of itself) after the write process is complete.

* 0x3f8 serial port logging support on lpc. (Sorry, I never looked into 
this)

* A couple of jumper pins could be preconfigured as host side software 
programmable GPIOs for tasks like triggering a reset on the target system.

* Deliver the dongle with a PLCC plug header, or offer it as an option.

Best regards,
Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

[Peter Stuge]

On Fri, Aug 08, 2008 at 03:02:13PM +0200, Stefan Reinauer wrote:
> Peter Stuge wrote:
> > * By far the most important one: Use a more intelligent USB chip
>
> * Possibly, in connection with this, use SRAM or DRAM to store or
> cache the images transferred from the host side. I think writing
> the flash takes about as long as transferring it over serial port,

Each 128K block erase+write takes at least 1.8s. Look for a flash
part with better performance for the next generation.
> so using a faster USB (network instead of serial) chip would only
> move the bottle neck.

Exactly how a fast USB interface should work is a great question.
Making the device a CDC Ethernet device like the GALEP-5 would be
nice because it will be easy to interface with, but it would also
require the FPGA to run a full IP stack, which I don't think we want.

I would look for other device class specs but possibly the best
solution would simply be a vendor specific device with two (IN+OUT)
bulk endpoints and an efficient protocol. As long as documentation is
provided, I don't think there's any shame in vendor specific devices.
(And with the dongle there's source.)
> * One habit of the dongle is very ugly; the need to reset it after
> loading it. I think it would be a good idea to have the dongle
> reset itself (or, the lpc part of itself) after the write process
> is complete.

Great point. It should not need a reset at all. Hopefully this does
not go beyond the VHDL.
> * 0x3f8 serial port logging support on lpc. (Sorry, I never looked
> into this)

Great idea, also VHDL. Besides Stefan's points I have another VHDL
request;

* Don't require explicit enable for full memory decode.
> * A couple of jumper pins could be preconfigured as host side
> software programmable GPIOs for tasks like triggering a reset on
> the target system.

Yes, some open collector outputs should be cheap to add.


//Peter

[Stefan Reinauer]

Peter Stuge wrote:
> > * 0x3f8 serial port logging support on lpc. (Sorry, I never looked
> > into this)
>
> Great idea, also VHDL. Besides Stefan's points I have another VHDL
> request;
>
> * Don't require explicit enable for full memory decode.

... or make the enable switch available both from the host and the 
target side...



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

[Marc Jones]

Stefan Reinauer wrote:
> Dear Martin-Éric,

> * 0x3f8 serial port logging support on lpc. (Sorry, I never looked into 
> this)

Good idea.

Power and reset headers are handy for remote development. Maybe the GPIO 
header could be used for that on the current model?

Marc


-- 
Marc Jones
Senior Firmware Engineer
[phone] Office
mailto:[e-mail]
http://www.amd.com/embeddedprocessors

[Stefan Reinauer]

Marc Jones wrote:
> Stefan Reinauer wrote:
> > Dear Martin-Éric,
> > * 0x3f8 serial port logging support on lpc. (Sorry, I never looked 
> > into this)
>
> Good idea.
>
> Power and reset headers are handy for remote development. Maybe the 
> GPIO header could be used for that on the current model?
> Yes, I believe it could be done. The bigger task though is getting the 
> "reset LPC part after flash update" part right. The VHDL code locks the 
> LPC side of the dongle during flash update, so no interference can 
> happen. But it stays that way after the update. There might be reasons 
> for that, I am not sure.

[Marc Jones]

Stefan Reinauer wrote:
> Marc Jones wrote:
> > Stefan Reinauer wrote:
> > > Dear Martin-Éric,
> > > * 0x3f8 serial port logging support on lpc. (Sorry, I never looked 
> > > into this)
> >
> > Good idea.
> >
> > Power and reset headers are handy for remote development. Maybe the 
> > GPIO header could be used for that on the current model?
> > Yes, I believe it could be done. The bigger task though is getting the 
> > "reset LPC part after flash update" part right. The VHDL code locks the 
> > LPC side of the dongle during flash update, so no interference can 
> > happen. But it stays that way after the update. There might be reasons 
> > for that, I am not sure.

Ah, I see. That would be a problem. Power and reset would be good for 
the automated testbed.

I can't find the twiki page for the automated testbed. Can you put a 
link on the mainpage or the qa page?

Marc


-- 
Marc Jones
Senior Firmware Engineer
[phone] Office
mailto:[e-mail]
http://www.amd.com/embeddedprocessors

[Stefan Reinauer]

Marc Jones wrote:
> Ah, I see. That would be a problem. Power and reset would be good for 
> the automated testbed.
> absolutely.
> I can't find the twiki page for the automated testbed. Can you put a 
> link on the mainpage or the qa page?

On the mainpage, go to Developer -> Testsystem

Stefan



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

[bari]

Take a look at the VHDL source for both the the Xilinx and Altera fpga's at
http://www.sump.org/projects/analyzer/

All the work is almost done for you. Just add your LPC VHDL and build on 
the Java interface for a complete, spi and lpc interface plus flash 
emulator and logic analyzer, with serial, usb (host and device) and vga 
ports.

-Bari

Martin-Éric Racine wrote:
> Greetings,
>
> Noticing that the main community of users for Artec Group's LPC dongle
> has been at Coreboot, I have two announcements to make:
>
> 1) The current LPC dongle model is EOL.  Some components no longer exist
> on the market so, after the batch we're producing this month, it's gone.
>
> 2) We're already working on a new LPC dongle to replace the current one.
>
> In conjunction with item #2 above, we are hereby giving the Coreboot
> community an opportunity to influence the design of this new product.
> While we cannot guarantee that every idea submitted will be used, we
> will definitely be reading all the feedback we receive.
>
> The end result will be an even better LPC dongle that serves the growing
> needs of the embedded hardware developer community.
>
> To compare with the current dongle design, see:
>
> http://artecgroup.myshopify.com/products/programmable-lpc-dongle
>
> Looking forward to receiving your ideas for this new LPC dongle product.
>
> Best Regards,

[Carl-Daniel Hailfinger]

Hi Martin-Éric,

On 08.08.2008 13:15, Martin-Éric Racine wrote:
> Noticing that the main community of users for Artec Group's LPC dongle
> has been at Coreboot, I have two announcements to make:
>
> 1) The current LPC dongle model is EOL.  Some components no longer exist
> on the market so, after the batch we're producing this month, it's gone.

That's unfortunate.
> 2) We're already working on a new LPC dongle to replace the current one.

Now that's great.
> In conjunction with item #2 above, we are hereby giving the Coreboot
> community an opportunity to influence the design of this new product.
> While we cannot guarantee that every idea submitted will be used, we
> will definitely be reading all the feedback we receive.

Cool, thanks for giving us this opportunity.
> The end result will be an even better LPC dongle that serves the growing
> needs of the embedded hardware developer community.

A few suggestions to improve on the already great dongle:
- It's a LPC dongle, but having SPI support as well would be really cool.
- Maybe sell a dongle<->PLCC32 connector as well.
- Provide a memory access (read/write) logger with timing info.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> > The end result will be an even better LPC dongle that serves the growing
> > needs of the embedded hardware developer community.
>
> A few suggestions to improve on the already great dongle:
> - It's a LPC dongle, but having SPI support as well would be really cool.

BTW, for SPI I can very much recommend the Dediprog SF100. It's quite
inexpensive, and allows you to program flashes in-place.
Only downside: It requires Windows (in a VM)

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

[Ed Swierk]

On Fri, Aug 8, 2008 at 4:15 AM, Martin-Éric Racine
<[e-mail]> wrote:
> In conjunction with item #2 above, we are hereby giving the Coreboot
> community an opportunity to influence the design of this new product.
> While we cannot guarantee that every idea submitted will be used, we
> will definitely be reading all the feedback we receive.

The current LPC dongle is great--I've been using it for a couple of
weeks and it speeds up firmware debugging enormously.

Here's my wish list for a new version of the dongle (some of which
overlap previous responses). I'd like to be able to:

1. Reset the dongle by issuing a command from the host, instead of
pushing a button on the dongle.

2. Reset the target by issuing a command from the host that toggles a
GPIO connected to a reset pin on the target.

3. Enable 4MB addressing by setting a jumper on the dongle or by
issuing a command from the host.

4. Purchase a prewired PLCC32 LPC/FWH plug adapter instead of hunting
for parts and assembling them myself.

5. Pay via credit card. I would happily pay you a surcharge to avoid
the time and expense of dealing with checks and banks and wire
transfers.

--Ed

[Ward Vandewege]

On Mon, Aug 11, 2008 at 08:20:57AM -0700, Ed Swierk wrote:
> The current LPC dongle is great--I've been using it for a couple of
> weeks and it speeds up firmware debugging enormously.
>
> Here's my wish list for a new version of the dongle (some of which
> overlap previous responses). I'd like to be able to:
>
> 1. Reset the dongle by issuing a command from the host, instead of
> pushing a button on the dongle.
>
> 2. Reset the target by issuing a command from the host that toggles a
> GPIO connected to a reset pin on the target.
>
> 3. Enable 4MB addressing by setting a jumper on the dongle or by
> issuing a command from the host.
>
> 4. Purchase a prewired PLCC32 LPC/FWH plug adapter instead of hunting
> for parts and assembling them myself.

I second all those points!

Thanks,
Ward.

-- 
Ward Vandewege <[e-mail]>
Free Software Foundation - Senior Systems Administrator

[Martin-Éric Racine]

Ed Swierk kirjoitti:
> 5. Pay via credit card. I would happily pay you a surcharge to avoid
> the time and expense of dealing with checks and banks and wire
> transfers.

This is already possible since a few weeks:

http://artecgroup.myshopify.com/products/programmable-lpc-dongle

-- 
Martin-Éric Racine
Business Development Manager
Artec Group OÜ

[Ed Swierk]

On Mon, Aug 11, 2008 at 8:20 AM, Ed Swierk <[e-mail]> wrote:
> Here's my wish list for a new version of the dongle (some of which
> overlap previous responses). I'd like to be able to:
>
> 1. Reset the dongle by issuing a command from the host, instead of
> pushing a button on the dongle.
>
> 2. Reset the target by issuing a command from the host that toggles a
> GPIO connected to a reset pin on the target.
>
> 3. Enable 4MB addressing by setting a jumper on the dongle or by
> issuing a command from the host.
>
> 4. Purchase a prewired PLCC32 LPC/FWH plug adapter instead of hunting
> for parts and assembling them myself.
>
> 5. Pay via credit card. I would happily pay you a surcharge to avoid
> the time and expense of dealing with checks and banks and wire
> transfers.

One more wish, if you're still taking requests:

6. Log to the USB serial port LPC flash reads and writes (similar to
the existing POST code logger mode).

--Ed

[Martin-Éric Racine]

Ed Swierk kirjoitti:
> On Mon, Aug 11, 2008 at 8:20 AM, Ed Swierk <[e-mail]> wrote:
> > Here's my wish list for a new version of the dongle (some of which
> > overlap previous responses). I'd like to be able to:

[...]
> One more wish, if you're still taking requests:
>
> 6. Log to the USB serial port LPC flash reads and writes (similar to
> the existing POST code logger mode).

We're always open to suggestions, but these will have to be sent to our
FPGA developer, Mr.Jüri Toomessoo at the above address, in the future,
as this is my last week working for Artec Group.

-- 
Best Regards,
Martin-Éric