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.
Tuesday, 17 April 2007
Friday, 23 March 2007
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:
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)
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:
This is a possibility of a possible solution to the physical design:
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 peripheral layer:
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
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
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
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.
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
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
Wednesday, 21 March 2007
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.
Subscribe to:
Posts (Atom)