JTAG tutorial

nice tutorial on using jtag (for fpga but relevant for all) at:
http://www.fpga4fun.com/JTAG.html
also lots on using it with a microcontroller on all fpga vendor sites, but less easy to read.

Description of possible solution

The art in this is not accurate as I copy pasted wrong and drew for easyness.

This is a possibility of a possible solution to the physical design:

The system is composed of 3 stacked boards as bellow:

The first layer is the programming layer:The drawing for this layer is accurate. A cheap SPI MAC chip, and a cheap 8 bit microcontroller mabye with just enough ram to hold a packet, or maybe with a minimal TCIP implementation.

This could program basicly anything through jtag and would have the capability to list and program all devices on board under instruction of the ethernet.

The Microproccessor layer:

On this layer I forgot to put in an extra (optional) bus leading up to the next, for possibly connecting to USB devices. If you put on the right microproccessor you could connect in USB keyboard, mouse, (graphics card? or would you use an LCD peripheral)

The peripheral layer:

Dont be put off by the number of chips drawn its just random. The chip count would be rather less, and proporitional to the number of peripherals attatched.

Advantages of this implementation:

• Flexibility - JTAG is used for programming, anything jtag supporting could be put as the second board up, including FPGAs, any proccessor, maybe even a PIC if you put an adapter on.
  
• Robustness - It is not possible for the programmer to break the reprogrammability
• "Encapsulation" - Each layer is isolated from the others, and simply needs to produce a complient output for the next layer. This makes it very easy for developers to design say a new peripheral layer maybe with a peripheral mounted on it, or a new microproccessor layer.
• Staged development - The first stage would be to use a PIC to program an FPGA board via jtag, the next to design a board to do that, and test it, the next to design the microproccessor layer, the next to make some peripheral boards

Opinions?

proccessors

I am looking at the motorla coldfire proccessor.
If we use a seperate system for programming these would be a really nice implimentation option.
They are widely compiler supported, come in packages we like and are "aggressively" cheaply priced at 10-20 pounds. Very fast, with integrated memory controllers, often ethernet, and a lack of all the other unneccesary peripherals often offered. in other words maybe ideal.

Something like this would be ideal, note the price tag, onboard ethernet and UART (for peripherals, one can be used for all the peripherals).
Will shop around for availability, speed, and on board size minimization

2 chip cheap solution

we could:
use one of these controllers from microchip (or 2) for the ethernet MAC.
They are 2 dollars each (silly money).
We could couple this with a really cheap 8 bit controller for programming.
Also we could use a cheaper FPGA as a mac is about the size or the proccessor core and I was having trouble fitting it on a smaller FPGA.
Coupled with another package (not VQ100 but surface mount) available it would be a good, cheap solution.

It communicates with the proccessor chips by SPI (serial), which is easy to find on a microcontroller and is a small, free FPGA core.

Actel FPGAs are a bit expensive (£20), so we will have to weigh arm VS cost, unless we can find another alternative.
Driver writing for an OS might be needed, but would be a small matter for a more custom node implimentation based on your compiler as we'd need to do it anyway, plus I think it would be a small matter.

Also as we now have an external mac, a proccessor + memory + peripheral controller implementation might be an idea, I'll look into it, although giving the user a programmable FPGA and memory on a remotely programmable board is a nice idea.

SH

+ what proccessors does CILC compile for? I'll try and find a way of using one of them

ideal complier

http://en.wikipedia.org/wiki/Cilk
this probally would be the high level complier i'd modify to run on mutiple nodes.

so goals from software prespective are

networking/simple os

V
remote procedure call / object orentation (nodes programed as isolated objects)

V
Cilk or other highlevel processor which ulitizes the nodes as processors.

V
C++/C to Cilk (automated paraelleism) and node perfifals are 'devices' in a general 'serial' program.

Another premade SoC.
This one only 1.5cm accross.
External memory control but not sure how much (16 bit but maybe with banks. it mentions 24...).
Retail £10, includes ethernet, usb, and arbitrary IO (for peripherals)

Continuing to persue FPGA options. Currently looking at actel.
They do "better" FPGAs for the purpose and more to the point an ARM core not a vendor made up one, further they do some surface mount FPGAs with more pins i.e. better for our purpose.

Further, looking into a cheap way of doing the 2 chip programming thing. If I can find a really cheap chip to do it with, maybe the lowest rated xilinx FPGA, or the cheapest ethernet enabled 8 bit proccessor I can find. it might be worth doing cost for cost as it takes away from the possiblity of the user "breaking" the in system programming capability and needing to re-image their board (might not be a possibility for them), wether we use a SoC or an FPGA.

SH

just doing abit of reading

i was looking at insect nervious systems, apperently they do alot of preprocessing before the information hits the main nerve cluster, i can imagain ride being simular.

another paradim

http://en.wikipedia.org/wiki/Autonomic_Computing

another one

http://particle.teco.edu/devices/devices.html

directions...

John:
a note on a few issues -
First, I agree that it is not necessarily desirable to have a £10 board driving each motor.
There are a number of ways of handling the issue, one of which is use of small controllers, and another is the use of multiple peripherals, i.e. a single node does both motors, and another does the sensors.

It is important not to lose sight of two factors:

1. This is a prototyping system not a production system. A production system of any run length (i.e. the kind where cost is an issue) would have a hardware competent team implementing a already pro typed system, and not need RIDE. The pro typing team might though.
   
   Therefore, it is not important to have cheap peripherals and expensive peripherals, as tbh they are all pretty cheap. I have checked the price of a ethernet PIC. it is "from 4.95". Thake into account this is for thousands. it probably about 8. I am not sure there is a price case.
   
2. The whole point of the ride system is to insulate developers from the bits they are bad at. That doesnt mean that they should be limited to using the peripherals we have implimented, rather it is VITAL that there be a simple way of implimenting new peripherals, and writing programs for them in a way that is ISOLATED from the software guy. For instance writing a class. I like the whole "use memory maps to make pixels look all the same, solder on an ADC or PWM chip" thing. The whole point of using an addressing system was to allow large numbers of peripherals to be connected to a node.
   

There are big issues with the use of PICs, I dont see a case for their use. I think there are software issues with a mixed PIC/proccessor implementation, not least that the PIC compiler must know what type of PIC it is compiling for.
I don't think there is a cost case for a smaller controller, but there may be a size case.
I don't object in principal, but I fear for the "distributed processing" angle to be valid, a pure micro-controller only implementation is not viable, and a mixed implementation will cause issues for both of us. In short, no point, lots of work, so why?

RE linux:
linux is an operating system. PICs dont have an operating system, they just have one program. Basicly the difference between a computer with an OS, and a computer without, is the difference between a GUI and a command line ap. There are some things you just dont need a GUI for, running a webserver is one of them - it just goes off, works and doesnt need to show stuff.

If you wanted a platform to run a distributed processing deamon which could also carry out hardware operations (a cool solution) linux would be a good idea: you'd want multi threading and shit. If we are buidling a robotics suit, linux is not necessary.

The deamon idea is a cool one, lets chat about it next coffee.
I vaguely remember a language called ADA (with its C++, objectADA). might be cool.

new direction?

I was just thinking ?

rather than producing just one node type with a X processor, possibly we could view to problem as a stack simular to that of an network stack in that,

for example the functions (Set pos, Get pos) for a servo could be implimented on a 8 bit processor. but not much else could be implmiented or advanced processing.

but for say, well the control of these motors would require another better processor say 16 bit.

etc...

so these differn't processor could communicate on the same line(ethernet). and program via the ethernet.

what i'm saying is, we should shape the hardware powerfullness to it's appilcation.

another possiblity, is having 'none programmable' devices, so for example the servo only has getpos and setpos functions and none user defined ones. and the processing is automatically lumped with the larger nodes implicitiy

// personally i like this method, because i feel we could churn out a loud of devices using ethernet enabled pics. and we only have to make one processing node. but it also limits the possiblites of concurrent programming.

so what we would be looking at is a centralized processing with (2 to power 8)*4 devices it can control.

another crazy thing we could do, is that the 8 bit objects are defaultly 'locked' but can be unlocked by the user to allow programming.

so we would be looking at something like

http://www.modtronix.com/product_info.php?cPath=1_36&products_id=73

for the simple nodes

btw i'm just throwing around ideas, before we commit to a spec.

//nb there is source out there made by the manufactues of pics which deals with TCP/IP already.

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1489

other OSes

http://ecos.sourceware.org/about.html

this seems to suit our purposes.

I mean we would have to right drivers for divices attached.

and it can work with 16 bit processor and smaller than linux.

so we could view using this os as what i would have to write anyway. and there is nothing to stop the devlopment of a package for linux to accept data in the format which this nodes use. and be able to process it.

the scariest thing i've ever seen

http://cswww.essex.ac.uk/staff/owen/machine/videos.html

this has to be the scariset thing i've ever seen, but this is kinda what i imagien RIDE being used for.

more micro computers running lunix

http://gumstix.com/
http://www.mini-box.com/site/index.html?gclid=CMOH5ebOgYsCFSYSQgodCGjVJw

i'm not putting these up as bench marks for RIDE, just 'of intreast'.

the way i see it, we should aim for cheap small units. and the power will be in the parallelism, not the processor and ram size.

***
with this in mind i'll look more into the trans-computer model. i agree linux would be cool. but a linux driven node, which meerly controls a servo, is over power to say the least.

I believe what we should  be looking for is. well more than a pic, but less than a gumstick. probally meaning that i would have to write a small os.

another possiblity is, well as we talked about nodes with larger processing capiblities. having a simple nodes running a super striped down version of linux for single servo controls and what not. which can still interface on the ethernet level with more robust nodes.

the way i see this linux, is well, why rewrite existing code. i guess we need to figure out if we would be just rewriting code (if i make an os), or coding it in such away that we remove the bulk of linux and only implimenting required functionity.

this is the other possiblity. which i feel goes again the RIDE concept. which is. implment tiny lunix manchines. then devolope usb devices (such as usb motor) to attach to these lunix manchines... this would be more of an reflection of the mutiple devices to 1 node. but this idea of a master controller breaks the object orinated apporach up. so it's kinda object oriented. but saying that, do we want a paradim to determine the RIDE. in that a node with servos which make up an arm could be thought as such.

node = arm
arm has muscles
muscles = servos.

but if we enforce that. then whos to say a devoper wouldn't say....

node = person
person has muscles
muscles = servos.

so then the advantage of the event driven concurrent system is lost ?

where as if we have the system made from muscles and a dispruduted program, this paraelleism is sustained and of course in the users source code he could store the arm object containing servo nodes.

these questions are hard, because we need access to poeple who are going to use this system.  or we target to use for it.

i think this is just a general problem of anything. things seem to go though fluxes of disproduted or centralized. 

and in terms or robotics.... centralized is avialble.

disproduted is not really that accessable.

***
the other thing is i see these sort of guys being our 'market'

http://cswww.essex.ac.uk/staff/owen/research.htm

i'm glad to see kevin warick isn't the only nutter in accademmia ?

***

another thing i realize my spelling is bad, i will spell cheak all posts before hand in.

The Bad news:
http://www.netburner.com/products/development_kits/network_development.html

This company produce our board AND an eclipse based network programming package.

The Good news:
Their products are too expensive for our target: $100+ usually quite a lot +

Open Source Hardware

John:
Indeed it might be very useful to look at.
I don't know about buying a board. It would eliminate my role in the same way as removing the distributed programming part eliminates yours.
However, almost the entire functionality of the board is contained on the proccessor chip, which is the same chip I posted in my last post. We could study and impliment a reduced version, or perhaps find a smaller lower feature processor.

As for Linux:
getting Linux to run on a system like this is a reasonably large task, but would be no harder on a home made board (even an FPGA based one) than on this, except this has a lot of the ground work already done. Its a case of device support and having a C compiler. I would be baffled if a linux device driver was not available for the FPGA Ethernet.

I don't dispute running Linux would be cool but it also introduces certain complications, and we may decide a simpler system would be more desirable.

Coffee to chat about it tomorrow?

I will examine varius alternative chips when I get time. These come in at about £15 each, but have a lot (and I mean a lot) of undesired functionality. Also although surface mount they have about 250 pins.

open source hardware

I decided to have alook at embedded lunix as a operating system. meaning that i would not have to worry about some of the lower level problems. and I found this :

http://en.wikipedia.org/wiki/ECB_AT91

being that it is open source hardware we can modify it and expand and stip it down. but it is basically a super node.

also lunix is open source, so the additional functionality can be implimented in the operating system.

what you think sam ?

****

http://wiki.emqbit.com/ seems they have the simular idea to use, but they have not intergrated it into one devlopment tool.

if we do use this as a bases for RIDE, maybe we should consider buying a board ?

also, i realize the boards are abit big around (8cm by 8cm ) but possibly we can strip it down or have muitple board with a jumper bus to increase it's 3d diamentional space but decrease it's 2d profile.

Two microcontrollers / proccessors available from amtel may be suitable:
AT91SAM9263, AT91RM9200
http://www.atmel.com/dyn/products/product_card.asp?part_id=4056
http://www.atmel.com/dyn/products/product_card.asp?part_id=2983

more may be suitable

investigation to follow

SH

07/03/06 - FTAO John

John, here is how networking will look to your fine self, more or less. It might help you get some ideas of how to work it in.

Data is sent from and arrives at your system in lumps called "packets".

• A packet contains 46bytes to 1.5kbytes of "some data".
• It also contains a label saying the unique address of the person that sent it (some hex).
• it also contains a "packet type" which we can use to identify between programming, "function call/public variable get", and arbitrary packets like TCIP internet ones.
• All this data is CRC checked and therefore reliable, except bad data is simply thrown away so you have to make sure you don't miss data. TCIP handles this I think, we could use that? your area, look into it. I know how I'm doing it for programming.
  

SEND A PACKET:
To send a packet you:

• call a method I give you which assembles data you pass it (maybe as an array with size) into 1 or more packets, and then sends it.

RECEIVE A PACKET:

• when a packet turns up at a node, the node halts what ever task is now running. It is vital that the packet data be moved into the memory ASAP cos packets are ignored till its moved.
• If its a program data packet some preloaded routines I make take over and do the programming shit.
  
• If its a function call, well we have to talk about that, there are some QoS issues.
• If its arbitrary data, an arbitrary routine could be called that generically handles arbitrary data, you can make this routine do whatever you want or nothing at all.

So thats it, thats how our network works.
Note:

• Unlike most TCIP objects in java or whatever, when data arives, (in java terms) "an event is triggered", and it is handled there. Your welcome to disguise this by just buffering the data.
  
• For a "simulation" of this, use UDP packets not TCIP (its the other half of TCIP). This is probably a better way of doing routed packets over the internet btw, as its simpler.
• http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol
  Look into this, its UDP but doesnt lose packets. It will rout over the internet. May be too complex, I don't know.

EDIT: a C implimentation of RUDP, although its not copypasteable.
http://plan9.bell-labs.com/sources/plan9/sys/src/9/ip/rudp.c

05/03/06 - Acceptable devices ahoy!

today, working in trees lab, I saw that oswaldo had a load of devices that would suit us out.
They are: a liddle device with a Vertex 4, flash, and ethernet, on a 3cm by 6cm board.
The board has busses either side for connection.
This would basicly suit our purposes, although its a bit hefty, and has a cost of about £100 a node.
Hopefuly we could get the cost down to 15 or 20.
Plus ours would be smaller.

so basicly we have a protype platform acceptable for final delivery, which is frankly excesive to our needs (32 bit bus, vertex 4 FPGA capable of holding about 100 proccesssors, etc).

Yay. With this, assuming no hickups on the FPGA front, I see no reasonable objection to using FPGAs. Further, although they are hard to get hold of there is a bigger 5000 slice core for the package we want, which would be another way of removing the fpga capacity issue.

Anyway, I'm looking into specifics but we now know with certainty that the project as outlined is totaly viable.

05/03/07 - minor victories

1. oswaldo has told me how to access the EDK within the department.
2. although the microblaze is strictly speaking harvard architecture, its definitly possible and indeed well documented how to make it use a single memory bank, and if you use fast memory like DDR, then it doesnt disrupt the pipeline too bad.
3. I checked the pin out diagram for the VQ100. I was concerned too many pins might be clock or JTAG or whatever. Turns out its a 100 pin package, so 60 pins is 60 pins.
   Worryingly, these pins are arranged kinda randomly around the device. Multi layered outsourced boards might be a way to go. Especially if we ordered 10.

Apart from this, I have decided to handle programming in software, as this allows "on the board" stuff to be far more minimal. Also allows easier wrapping of packets in TCIP for routing or whatever. (?)

05/03/07 - Core and Size

On the plus side, it is definitly possible to use a 16 bit external memory controller with the microblaze. This page confirms this and gives some instructions.

/*I am trying to figure out how to fit a microblaze, and possibly a ethernet MAC into the
constraints of the 2100 slice core on the only xilinx FPGA it is viable to use.
I think our options on the MAC are:
1: dont use it, find a smaller / write a protocol
2: write a reduced version.

Remember: we dont need a lot of features like duplex, 10/100, etc. If their core id 1000 slices, ours only needs to be 100.
*/
EDIT: have found that there is another core that doesnt support DMA but is just 700 slices, which is "good". It does do interupts. If we do the programming in software (easy) then its a goer

Microblaze supports 700 to a very high number of slices.
Only experimentation will tell if the core can be kept within say 1000 without sacraficing functionality.
As for the network, I'll have a look into it, maybe if we are doing this it might be worth using the mesh? maybe not.

TODO:
experiment with microblaze on (significantly) a spartan 3E
read up on ethernet propperly

04/03/07 - Core and packaging

Assuming we go with an FPGA based design:
We looked at a couple of ways of attatching the device to the board. We cant attatch a BGA device directly so:
Either a BGA socket can be used or
We find a surface mount package.

The Xilinx Spartan 3E X200 is available in VQ100, a 66 pin surface mount chip the size of a fingernail (1.7cm ish).

66 pins is: at least 8 pins for power, JTAG, clock, etc. This is "not good".
We cant use a 32 bit bus straight out., thats about 64 pins (maybe less if 24bit address field).
If it is possible to find a ram output core for the Microblaze that suports 16 bit we could have:
64 meg of ram, and 2048 periferal addresses with:
16 bit ram: 16+16 = 32 pin
8 bit address = 8 + 8 = 16 pin
6 pin network = 6 pin
= 54 pins.
This will almost certainly fit, we could maybe increase the peripheral data bus width to 12.

Task:
Find a way of putting a 16 bit ram module on the Microblaze.

04/03/07 - Network ideas

Looking further into networking systems, I examined a number of alternatives.
If we used our own implementation for the network, it could have bugs in, so it would be better to use an existing system, for which cores or chips are available.

Originally we discussed using a mesh network. I was unable to find an existing wired mesh network. Zigbee is a wireless network with a maximum speed of 1 megabyte. It is available as a system on a chip. It has 3 types of node, the lower two being function and router nodes. Although function nodes are small, we would need something like the router node, which is larger.
I think that the only way to get a proper mesh wired network at the high bandwidth requirements we discussed, would be to research, develop, and implement such a network. This would be a project in itself. I might do it after finishing, as it does need doing.

CANbus is really too slow as are RS232 and a number of other IEEE defined specifications.

After examining a number of standards, I concluded that it would be a good idea to use Ethernet because:

• the bitrate is excessive, so a shared bus would not cause congestion problems
• the devices could be plugged directly into a computer, via its RJ45 port, this would make writing a software interface kind of easy.
  
• commercial devices such as switches could maybe be used.
• with a TCIP stack ontop, the global internet could be used for communication

Control messages:

• control messages would act as a interrupt
  
• the would be preprocessed by some HDL coded firmware, or maybe some flash software, to see if they were for programming.
• If not they would be either a function call or a global variable get call, these would be passed as an interrupt to the CPU.
  

In the present implementation, peripherals would be poled, no interrupts supported.

ethernet cores and SoC's are easy to find.

Sam - 03/03/07 Ideas

Tonight, I have been foccusing on alternatives for implimenting the embedded base system.
First I will discuss "the microcontroller alternative", an easy fast implimentation, that is lacking in some respects.

A technology for device programming exists. It is called JTAG. It is used to program multiple devices on a board, and supports FPGA programming, FLASH programming, and ARM microcontroller programming. We could get an arm controller with CANBUS, and put wires between boards with canbus and JTAG wires. This would basicly be a solder job with PIC like functionality, and most things we need on the chip. Memory and program sizes would be in KB.

Alternativly we could use a softcore proccessor to impliment a full embedded system. The advantages of such an implimentation would be:

• Flexible peripherals for easy node creation (by extention board, or by soldering an FPGA , flash, and periferals to a small dedicated board, and flashing the FPGA with our binary file)
  This would bring new node time down to basicly board design and simple C.
  
• Huge memory: up to 2 gig of addressable space, including memory and periferals.
  
• Department liscenced easy to use "code" for most of the stuff:
  The department has a lisence for Xilinx Embedded Kit.
  This allows creation and configuration of a system with wizards.
  It brings my dev work down to writing the network and possibly a periferal bus. It can be easily used for everything envisaged so far
• Potential for cool stuff:
  *Embedded linux is a possiblity
  *Node proccessor implimentations are fed as parameters to the compiler. They could be supplied by a node designer allong with their node class. This allows: add random "extra instruction" hardware to the board for specialist node needs, maybe a hardware perceptron for neural network nodes
  *It is definitly possible to reprogram the hardware the same way as we are talking about reprogramming the software. Its not something I'd want to try till everything else is done, possibly even till after handin, but if you put generic connectors on, you could have say a MP3 player node 2 proccessors and a hardware MP3 codec change into a grahpics node with a hardware 3D engine !Crazy Shit!

Summary of implimentation of option 2:
Board would have:
Flash and or RAM (i.e. if you never power down just ram is cool)
FPGA
Peripherals

FPGA would have:
microblaze, possible custom "peripheral bus" memory mapped hardware access, custom network.

The above would work as described.

Dev time (wild estimate)
2 weeks to experiment with microblaze
2 weeks to get a test design working that is just an embedded computer on a dev board
3 weeks to get a network implimented
1 week driver writing, hand over software to you at this point
2 weeks for board design (ORCAD is a fucker)
3 weeks build time.

As you can see I will need to start the development in summer so I can hand you a dev board to play with for the software before I actually build it.

John - first post

Atm i am looking into simulating another university project (a mobile robot) . Knowing that it is probable that we are going to go ahead with object orientated hardware project I am going to program the simulation in such a way that it reflects how the nodes will be programmed to figure out exactly how a person my program the nodes.
one my think of this as a feasibility study,

02/03/07 - Initial ideas and architecture review

As stands, I am looking at varius alternatives for the proccessor implimentation.
Options are:
1: A comercial microcontroller (i.e. a PIC)
2: A comerical microproccessor (many many many)
3: A microproccessor on an FPGA

1: simple, but programming may be a problem, we might end up putting two PICs on, one to handle the network and the programming. Advantage is that they are easily available in easy packages.

2: I dont really see the advantage of this over a PIC based system. I have ideas over how you could make it do the programming, but I think that in terms of the network it might be a fucker.

3: Microproccer and network on an FPGA with a vendor provided or possibly opencores risc softcore proccessor - If we could use the vendor "Altera" for our FPGAs this would be quite easily realizable. I have looked into packaging, it is sometimes possible to get surface mounted FPGAs, not BGA ones, but we might find it prefforable to get a socket for BGA ones, and then buy BGA ones.
The reason I am enthusiastic to do this option if possible rather than the 2 PIC option which is my current 2nd favourite is the flexibility it would give us in terms of programming and periferals.
It seems that a lot of the soft proccessors come with all the work I would need to plug them into memory already done. FPGAs are a bit more pricy than pics.

As stands I'm reading up on embedded systems. I was chuffed to discover its a 20 credit module not a 10.

Joe Blogs

John, I thought this blog might help us coordinate the project. we can post reference stuff, thoughts etc, so that we stay in sync. Not so important now, but I think some online reference will be usefull later on