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.

 

[Sebastien Bourdeauducq]

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]

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]

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

 

[Mike Treseler]

> Dear Mr. Treseler,
> few years ago I followed quite closely the comp.arch.fpga and comp.lang.vhdl
> groups and I was fascinated by your template project especially the
> testbench style, that I adopted since then. ....
> Talking about your template, how do you see multiple component instantiation
> and port mapping, as opposed to your procedural template?

My top entity is a collection of direct
instances of single process entities with port maps.
I use the Quartus rtl viewer to draw a block diagram
from my functional code.
I use a template to simplify the synthesis of variables.

> I believe that component instantiation offers a black-box view pretty much
> like a schematic entry and it's easy to me to follow, while I don't have
> that picture through your procedural template. Am I missing something?

I agree at the top level.
I like to see the wired view, but I let quartus draw it for me.
I also click on on one of the top blocks on the rtl viewer
to verify the structural view of my procedural entity.

> Do you think a single process, as opposed to many of them, will simplify the
> datapath and allow for better maintainance of the code?

I instance single process entities at the top level.
I prefer to connect large boxes at the port map level to
connecting processes at the architecture level.

> What is the gain of having variables as opposed to signals?

I can write functional/procedural code for synthesis
using standard vhdl source code.

> I am very used
> to signals since I always though that the way values are assigned to a
> signal follow pretty much what happens on hardware, while for a variable
> there is an abstraction that I am not accustomed to.

I am very used to writing, siming and tracing code descriptions with
immediate assignments,
and letting synthesis sort out the LUTs and flops using my template.

> I hope I haven't bother you too much with my questions.
> Best regards,
>
> Al

Not a bother in the least.

-- Mike Treseler

 

[Alessandro Basili]

My top entity is a collection of direct
instances of single process entities with port maps.

Understood. Indeed one of my biggest problem is where to put the
boundaries of a component to allow for reusability. But I got your point
of having top levels (which may as well be part of a bigger project)
populated only by components instantiation through port mapping, while
hiding the logic as much as possible.

I use the Quartus rtl viewer to draw a block diagram
from my functional code.

Do you know of any open-source software capable of doing that?

I agree at the top level.
I like to see the wired view, but I let quartus draw it for me.
I also click on on one of the top blocks on the rtl viewer
to verify the structural view of my procedural entity.

Actually this is the hardest part for me. If I see pretty well the
single flops and gates in a multi-process and concurrent assignments
style, I lack the overall structure view and most of the time I need to
draw down (what I call "paper simulation") the datapath.

Indeed your template collects all the flops and the assignments in one
single tidy place.

procedure template_v_rst is -- My default.
begin -- a_rst is logically equivalent
if reset = '1' then -- Assumes synched trailing edge reset pulse
init_regs; -- reg_v := init_c; Variables only, ports below.
elsif rising_edge(clock) then
update_regs; -- reg_v := f(reg_v);Variables only, ports below.
end if; -- Synchronous init optional (state_v = idle_c)
update_ports; -- will infer port wires ok for reset and clock
end procedure template_v_rst; -- out_port <= reg_v; ports only,
-- no signals

which is only saying that a reset will initialize all the registers and
the clock will update them all, instead of doing this for every single
flop/register/counter in the architecture.

I can write functional/procedural code for synthesis
using standard vhdl source code.

Apologize but I didn't get your answer. What do you mean with
functional/procedural code? and what is standard vhdl? Is there a
non-standard vhdl?

 

[Mike Treseler]

Understood. Indeed one of my biggest problem is where to put the
boundaries of a component to allow for reusability. But I got your point
of having top levels (which may as well be part of a bigger project)
populated only by components instantiation through port mapping, while
hiding the logic as much as possible.

That's it.
Note that direct instances do not require a component declaration.

Do you know of any open-source software capable of doing that?

No, but the free version of quartus/modelsim has it.
That is a good starting point for a trial design.

Actually this is the hardest part for me. If I see pretty well the
single flops and gates in a multi-process and concurrent assignments
style, I lack the overall structure view and most of the time I need to
draw down (what I call "paper simulation") the datapath.

Imagine a vhdl description of the muxes and registers
in this schematic of a register stack:
http://mysite.ncnetwork.net/reszotzl/stack.pdf

Now compare that description to the 13 lines of code
in the update_regs procedure here:
http://mysite.ncnetwork.net/reszotzl/stack.vhd

Indeed your template collects all the flops and the assignments in one
single tidy place.

Yes. That's the idea.

procedure template_v_rst is -- My default.
begin -- a_rst is logically equivalent
if reset = '1' then -- Assumes synched trailing edge reset pulse
init_regs; -- reg_v := init_c; Variables only, ports below.
elsif rising_edge(clock) then
update_regs; -- reg_v := f(reg_v);Variables only, ports below.
end if; -- Synchronous init optional (state_v = idle_c)
update_ports; -- will infer port wires ok for reset and clock
end procedure template_v_rst; -- out_port <= reg_v; ports only,
-- no signals

which is only saying that a reset will initialize all the registers and
the clock will update them all, instead of doing this for every single
flop/register/counter in the architecture.

Yes, I still have to write the 3 procedures and run a sim to check them,
but note that the stack code is working on an abstract array of 32 bit
registers.

Apologize but I didn't get your answer. What do you mean with
functional/procedural code?

Code using variables, functions and procedures for hardware synthesis.

> Is there a
> non-standard vhdl?

There are functional languages based on c or python that can *generate*
vhdl code. That is different than just using vhdl source code
to do the same thing.

Good luck.

-- Mike Treseler

 

[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 <[email protected]> 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