spacewire project on opencores.org

[Alessandro Basili]

Hi everyone,
after some struggles I have eventually found the time to revive an old
project on opencores which hasn't been updated since a while:

a spacewire link and router.

I have just been assigned as co-maintainer since the original one seems
not available since a while.
I intend to bring back the status of the project to "planning", since I
would like to discuss again the structure of the project, starting from
the specification documentation and the overall design structure.

I'd like to stress that I am not a spacewire expert, but I have been
working on a "modified" version of it that is in use in the AMS-02
experiment (http://ams.cern.ch) which is ready to be launched next year
on the International Space Station.

At the moment I would like to share my motivation, hoping to find some
feedback and some interest.

The purpose of the spacewire standard is (citation from the
ECSS‐E‐ST‐50‐12C):

- to facilitate the construction of high‐performance on‐board
data‐handling systems;
- to help reduce system integration costs;
- to promote compatibility between data‐handling equipment and subsystems;
- to encourage reuse of data‐handling equipment across several different
missions.

In this respect a handful of firms have grown to provide SoC know-how
and system integration capabilities to "serve" space exploration and
space science. ESA for example is promoting R&D in order to improve
european space industry sector.
Even though I do understand the commercial impact of this approach, I
still believe that we can do much more through an open platform,
improving the quality of the solutions and allowing for a greater
spectrum of products.
In my limited experience I have been working on two space experiments
(pamela.roma2.infn.it and ams.cern.ch) and witnessed other four at least
(ALTEA, GLAST-FERMI, LAZIO-SiRAD, AGILE). A great deal of development
was focused on the onboard data-handling systems, with ad-hoc interfaces
and non-standard solutions.
We had the possibility to adopt spacewire, but the "closed" solutions
provided by the industry is rather counter productive in an open
environment like the one of the academic collaborations we have (costs
are rather high and liability is often unclear).
This is where open IP cores may come in action and empower low-budget
experiments to build reliable and reusable systems cutting the
development costs and enabling them to focus on science.
The industry itself may benefit from this approach, since a good
licensing policy (like the LGPL) may foster interests and wide spread
the usage (hence enhancing the reliability) of these IP cores.

A more reliable and widely used standard gives a tremendous boost to our
space related dreams and even though it's just a piece of wire, I
believe it still build bridges worldwide.

Any feedback is appreciated.

Al

p.s.: this post will be on opencores.org forum as well.

--
Alessandro Basili
CERN, PH/UGC
Electronic Engineer

 

[Sebastien Bourdeauducq]

On 8 déc, 20:10, Alessandro Basili <alessandro.bas...@cern.ch> wrote:

after some struggles I have eventually found the time to revive an old
project on opencores which hasn't been updated since a while:

I would not bother. Why not simply use GRLIB's code?
http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=357&Itemid=82
While GRLIB also has some of the problems that plague most Opencores
designs (namely, slowness and resource utilization through the roof),
at least the cores work, are supported and are well documented.

S.

 

[Alessandro Basili]

On 12/9/2010 11:36 AM, Sebastien Bourdeauducq wrote:

On 8 déc, 20:10, Alessandro Basili<alessandro.bas...@cern.ch> wrote:
after some struggles I have eventually found the time to revive an old
project on opencores which hasn't been updated since a while:

I would not bother. Why not simply use GRLIB's code?
http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=357&Itemid=82
While GRLIB also has some of the problems that plague most Opencores
designs (namely, slowness and resource utilization through the roof),
at least the cores work, are supported and are well documented.

S.

I believe you are referring to the gpl package and not to the
copyrighted version. I don't quite believe you would have so much
support (at least from them) unless you get the proprietary one and
secondly the GRLIB promotes the AMBA bus as SoC, which is a rather
complex bus compared to the Wishbone.

IMHO GRLIB is a great effort to provide a fully integrated system on
chip (either FPGA or ASIC) that I do not dare to achieve (or compete
against). On the contrary my intent is to have a simple enough IP Core
which can be easily integrated and reused in order to promote the protocol.

But I do appreciate your comment and I will consider the possibility to
publish only the spacewire part out of the whole library, maybe
stripping off the amba interface, even though I need to evaluate the
licensing issue.

Al

 

[Thomas Stanka]

On 8 Dez., 20:10, Alessandro Basili <alessandro.bas...@cern.ch> wrote:

after some struggles I have eventually found the time to revive an old
project on opencores which hasn't been updated since a while:

a spacewire link and router.

[..]

Any feedback is appreciated.

I think spacewire is not the best example for open cores (At least
unless you manage to get ESA as co-supporter which is unlikely as ESA
has allready spacewire cores).
Open cores tend to have a lack in documentation and verification,
which is a no-go for developing space electronics.
Even if you target on public science projects it is very likely that
you need to ensure the "space-readiness" in many aspects for a core
before you can use it.

For spacewire interface I consider the effort to proof the quality of
a core clearly exceeding the effort for writting the core for your
own.

Are you firm with developing according to ECSS-Q 60 02? I would expect
a core development to be complaint to this before using it without
further quality checking in case of the core not beeing provided from
ESA for a ESA project.

In case of detailed questions you may also conntact me by sending an
email. You should change the receive-address to thomas
@domain_from_email when replying.

best regards Thomas

 

[Alessandro Basili]

On 12/10/2010 3:57 PM, Thomas Stanka wrote:
[snip]

Open cores tend to have a lack in documentation and verification,
which is a no-go for developing space electronics.

There are documented results of projects that attracted space
applications (http://opencores.org/newsletter,2010,09,#n5), proving that
there is a certain interest in the open approach.

Even if you target on public science projects it is very likely that
you need to ensure the "space-readiness" in many aspects for a core
before you can use it.

The aim of the project is not to provide a "ready-to-use" solution, but
to spread the use of spacewire protocol. The end-user is of course
responsible for the entire process, but it can be foreseen a test
campaign which will validate the IP on certain technologies (after all I
am working at CERN and there are a lot of test-beams facilities here!).

I just want to mention that on an FPGA based application the choice of
the FPGA may guarantee certain level of radiation hardness, while
specific design techniques may improve the level of hardness even
further (TMR, data-scrubbing, EDAC.).

For spacewire interface I consider the effort to proof the quality of
a core clearly exceeding the effort for writting the core for your
own.

Indeed, nevertheless there are a good amount of projects which are
neither proofing the quality of their cores, nor applying any standard
protocol throughout their systems.

Are you firm with developing according to ECSS-Q 60 02? I would expect
a core development to be complaint to this before using it without
further quality checking in case of the core not beeing provided from
ESA for a ESA project.

Even though I believe that Space Agencies around the world are
politically and technically bond to follow standardization processes
based mostly on lessons learned, I also believe that a lot of industries
and research institutes are buried under the burden of those standards
where a good chunk of their budget goes.

I am not advocating a deviation from the standards, on the contrary I
believe that protocols (as can-bus, mil-std-1553, spi, I2C...) are key
components of a reliable system and any effort should be made to make
them popular.

In case of detailed questions you may also conntact me by sending an
email. You should change the receive-address to thomas
@domain_from_email when replying.

best regards Thomas

Al

p.s.: I am just an enthusiast designer, willing to improve my skills and
to share my knowledge.

 

[Paul Colin Gloster]

Alessandro Basili <alessandro.basili@CERN.CH> sent on December 13th, 2010:

|-------------------------------------------------------------------------------|
|"On 12/10/2010 3:57 PM, Thomas Stanka wrote: |
|[snip] |
|> Open cores tend to have a lack in documentation and verification, |
|> which is a no-go for developing space electronics. |
| |
|[..]" |
|-------------------------------------------------------------------------------|

Verification is not always tried, though it has been dishonestly
claimed to have been achieved in publications such as
Sergio Saponara; Francesco Vitullo; Esa Petri; and Luca Fanucci,
"A Reusable Pseudo-Random Verification Environment for Complex Digital Designs: the SpaceWire Interface Case Study",
IEEE International Workshop on Intelligent Data Acquisition and
Advanced Computing Systems: Technology and Applications
21-23 September 2009, Rende (Cosenza), Italy.
Testing some examples instead of proving is not verification.

|--------------------------------------------------------------------------------|
|"I just want to mention that on an FPGA based application the choice of the FPGA|
|may guarantee certain level of radiation hardness," |
|--------------------------------------------------------------------------------|

Choose Aeroflex:
WWW.Aeroflex.com/ams/pagesproduct/prods-hirel-fpga.cfm

|-------------------------------------------------------------------------------|
|" while specific design |
|techniques may improve the level of hardness even further (TMR, [..]" |
|-------------------------------------------------------------------------------|

TMR could actually be harmful when using technologies with small
feature sizes, if sufficient care is not taken:
Blum and Delgado-Frias,
"Schemes for Eliminating Transient-Width Clock Overhead From SET-Tolerant Memory-Based Systems",
"I.E.E.E. Transactions on Nuclear Science", June 2006.

|-------------------------------------------------------------------------------|
|"[..] |
| |
|Even though I believe that Space Agencies around the world are politically and |
|technically bond to follow standardization processes based mostly on lessons |
|learned, [..] |
|[..] |
| |
|[..]" |
|-------------------------------------------------------------------------------|

The European Space Agency does not adhere to its own standards.

Yours sincerely,
Paul Colin Gloster