please look the campaign update log, we have 14+3 developer boards ready, so the very very first ones we ship out this year. I did hope to get Rev 2 PCB also ready this year, but, well it will be first week of January.
Yes there is dual core A9, that is the BOOT engine and reason why the SD card is not visible to P1, A9 can load different P1 version from SD card, so if the first P1 configuration, does request SD access as well, see where the sharing issue comes.. or if P1 changes SD card mode to SPI, then this is fatal as the A9 can not use SPI mode (maybe it can but no one has ever tried)
if some one wonders WHY FPGA+ARM and not plain FPGA:
"Zynq is the best Artix" (Artix is the low cost Xilinx FPGA, zynq is their SoC FPGA) - so the Zynq can be considered as FPGA that can boot from SD card. I like it. I like a lot, Xilinx promised that 10 years ago, now its reality.
Okay, I think I understand. If I pledge 250 Euros then I become an early adopter and can get one of the current batch of boards? I'm afraid that's beyond my budget. I'll have to wait for the production run I guess. It looks like a nice board though! Why not mention the Propeller on the project page? Are you waiting for Parallax to firm up their license changes?
I can probably allocated some of the existing boards for the 39 EUR deal also, but not so many it would be unfair, sorry about this.
yes the discussion is going way off here from original subject, no I am not waiting anything, but well I have to make 5 different FPGA projects to work, or was it 9, so I really busy, and not did consider proper separate posting, I should.
I can probably allocated some of the existing boards for the 39 EUR deal also, but not so many it would be unfair, sorry about this.
yes the discussion is going way off here from original subject, no I am not waiting anything, but well I have to make 5 different FPGA projects to work, or was it 9, so I really busy, and not did consider proper separate posting, I should.
Yes, I suspect the people that donate at the 250 level would be upset to find that some people got early boards at the 39 level. Anyway, good luck with your project. It looks like a great product!
Could the P1 get access to the SD card through the ARM chip? It would just require a high-speed serial link between the P1 and the ARM, and some code on the ARM that would respond to I/O commands from the P1.
oh yes of course.. I think that is much better way actually. It is possible to fully emulate the 64K EEPROM, so that prop IDE or whatever tools can read and write it, and the A9 sees that as dual port ram and writes to out SD card. Similarly it is possible to emulate SD card so that P1 sees real SD card, but the accesses are emulated. Or then use some API interface to have access to the SD.
All HUB memory is DUAL ported and visible in ARM memory space also.
But I am afraid some API and method should be figured out how to todo IPC inter-process-communication between P1 ARM
It is late here, I try to have some project page and more info in the next days.
I created new forum entry, will explain the tech details there.
3.5mm jack is gone, replaced with DIP14 header, where we have 8 IO, 1 analog input real ADC, and 1 analog out, "propeller video dac 4 resistors)
USB, yes no: CLG225 package has limited bondout on the peripherals, so the USB ULPI pins are used for other purposes and they can not be rerouted over FPGA pins either.
Ethernet can be used with RGMII phy, it would use 7 pins and provide 100Mbit wired networking.
I created new forum entry, will explain the tech details there.
3.5mm jack is gone, replaced with DIP14 header, where we have 8 IO, 1 analog input real ADC, and 1 analog out, "propeller video dac 4 resistors)
USB, yes no: CLG225 package has limited bondout on the peripherals, so the USB ULPI pins are used for other purposes and they can not be rerouted over FPGA pins either.
Ethernet can be used with RGMII phy, it would use 7 pins and provide 100Mbit wired networking.
- uSD and other I/O that is not currently mapped to the prop core could go on a "Port B"
- perhaps map some I/O's between the prop core and the A9 for fast communication
- the more hub the better
- if there is enough logic to implement more cogs, please consider it
- consider a 64 pin DIP with more prop I/O
---- can not say the max possible target clock, it would depend on the optimizations and selected options
--- uSD, id prefer it to remain on A9 only from boot-process safety reasons, access from prop to SD can still be implemented
--- prop to HOST: thats a good point would be nice to define some somewhat standard was to use prop ask IO accelerator/IO processor
--- "base" prop v1 takes exactly 1/3 of the block ram from 7010 device so the rest can be used also
--- there is logic to use, but stage 1 would be standard P1 compliant setup
--- more io, dip64, well the CONNECTOR is always a problem, DIP40 is still ok, DIP48 maybe also, if it goes as large as DIP64, then well there it comes more problematic, i would prefer PLCC68 format, but unfortunately all the known methods of building PLCC68 socket compliant devices are too expensive. It is possible with PCB only tech, and there are 2 or 3 variants of PCB to PLCC68, well as said none of them is as easy to use i would select it. Well its an ever going search for the form factor.
--- more io, dip64, well the CONNECTOR is always a problem, DIP40 is still ok, DIP48 maybe also, if it goes as large as DIP64, then well there it comes more problematic, i would prefer PLCC68 format, but unfortunately all the known methods of building PLCC68 socket compliant devices are too expensive. It is possible with PCB only tech, and there are 2 or 3 variants of PCB to PLCC68, well as said none of them is as easy to use i would select it. Well its an ever going search for the form factor.
A strong appeal of DIP40, is the Prop already has that form factor. So it should be first.
PLCC68 can be done with PCB tech, I did have a long conversation with the technology master at www.brandner.ee (they can make lots of funny things..). They said, yes we can do. But it would not be very cheap to make as it requires high precision routing.
I have made different type of "cut hole" PCB stamps, this is acceptable and doable, sometimes.
So we back to DIP40.
I already added DIP14 as EXTENSION slot that should for extra I/O.
I can probably allocated some of the existing boards for the 39 EUR deal also, but not so many it would be unfair, sorry about this.
yes the discussion is going way off here from original subject, no I am not waiting anything, but well I have to make 5 different FPGA projects to work, or was it 9, so I really busy, and not did consider proper separate posting, I should.
Did you ever ship your existing boards? I think you said you were shipping one to me in December but I haven't received it. Have your plans changed?
What a great community of creative minds. I'm new to Parallax and the Propeller, but not new to the chip industry.
My two cents on licensing would be - for educational and not-for-profit use, the GPL may fit. For-profit is a whole different issue and perhaps (Ken) follow the Xilinx model for IP. I'd hate for some squabble to bury development of the next Propeller when a company hinges its profits on added functionality or meeting timing for an 8-processor GHz Propeller in a Virtex package (or on-chip for that matter) and can't deliver.
Comments
Yes there is dual core A9, that is the BOOT engine
if some one wonders WHY FPGA+ARM and not plain FPGA:
"Zynq is the best Artix" (Artix is the low cost Xilinx FPGA, zynq is their SoC FPGA) - so the Zynq can be considered as FPGA that can boot from SD card. I like it. I like a lot, Xilinx promised that 10 years ago, now its reality.
yes the discussion is going way off here from original subject, no I am not waiting anything, but well I have to make 5 different FPGA projects to work, or was it 9, so I really busy, and not did consider proper separate posting, I should.
All HUB memory is DUAL ported and visible in ARM memory space also.
But I am afraid some API and method should be figured out how to todo IPC inter-process-communication between P1 ARM
It is late here, I try to have some project page and more info in the next days.
I would suggest a separate topic here on this Module, with all that you have posted here as a starting summary.
'"* 3.5mm audio video jack, audio out video out (mappable to prop IO) - we are not 100% sure about this, but currently its planned in"
I guess this has the Raspberry Pi pin mapping ?
What Audio / Video levels / impedance are supported, and can this dual-purpose as Serial ? ( or even USB* ?)
* I think the XC7Z010-CLG225 also has USB HW ? - if that can be ARM enabled/disabled/sensed, it can come almost 'for free' here ?
3.5mm jack is gone, replaced with DIP14 header, where we have 8 IO, 1 analog input real ADC, and 1 analog out, "propeller video dac 4 resistors)
USB, yes no: CLG225 package has limited bondout on the peripherals, so the USB ULPI pins are used for other purposes and they can not be rerouted over FPGA pins either.
Ethernet can be used with RGMII phy, it would use 7 pins and provide 100Mbit wired networking.
I will keep a close eye on these developments.
What is your target clock rate?
Some suggestions, if you don't mind:
- uSD and other I/O that is not currently mapped to the prop core could go on a "Port B"
- perhaps map some I/O's between the prop core and the A9 for fast communication
- the more hub the better
- if there is enough logic to implement more cogs, please consider it
- consider a 64 pin DIP with more prop I/O
---- can not say the max possible target clock, it would depend on the optimizations and selected options
--- uSD, id prefer it to remain on A9 only from boot-process safety reasons, access from prop to SD can still be implemented
--- prop to HOST: thats a good point would be nice to define some somewhat standard was to use prop ask IO accelerator/IO processor
--- "base" prop v1 takes exactly 1/3 of the block ram from 7010 device so the rest can be used also
--- there is logic to use, but stage 1 would be standard P1 compliant setup
--- more io, dip64, well the CONNECTOR is always a problem, DIP40 is still ok, DIP48 maybe also, if it goes as large as DIP64, then well there it comes more problematic, i would prefer PLCC68 format, but unfortunately all the known methods of building PLCC68 socket compliant devices are too expensive. It is possible with PCB only tech, and there are 2 or 3 variants of PCB to PLCC68, well as said none of them is as easy to use i would select it. Well its an ever going search for the form factor.
A strong appeal of DIP40, is the Prop already has that form factor. So it should be first.
Maybe other extra IO can be added as extra rows, or on the ends ? - so DIP40 stays the basic factor.
Some modules also have edge-exposed connections, which is a nice way to get low profile mounting option at low cost
( eg http://media.digikey.com/Photos/FTDI%20%28Future%20Tech%20Devices%29/MFG_UMFT234XF_sml.jpg)
I have seen PLCC68 done with edge-plating, but it does not look a long-term-reliable method.
DIP40 is still ok, all those decades
PLCC68 can be done with PCB tech, I did have a long conversation with the technology master at www.brandner.ee (they can make lots of funny things..). They said, yes we can do. But it would not be very cheap to make as it requires high precision routing.
I have made different type of "cut hole" PCB stamps, this is acceptable and doable, sometimes.
So we back to DIP40.
I already added DIP14 as EXTENSION slot
My two cents on licensing would be - for educational and not-for-profit use, the GPL may fit. For-profit is a whole different issue and perhaps (Ken) follow the Xilinx model for IP. I'd hate for some squabble to bury development of the next Propeller when a company hinges its profits on added functionality or meeting timing for an 8-processor GHz Propeller in a Virtex package (or on-chip for that matter) and can't deliver.
Neat stuff here.