Is there any point in adding 10Base-T to the smart pin?
cgracey
Posts: 14,133
After USB, this should be simple, but does it matter in 2016?
Maybe wifi is more the expectation, but could that be done via full-speed USB dongles?
Maybe wifi is more the expectation, but could that be done via full-speed USB dongles?
Comments
Have you talked to Treehouse about how much room you have left after USB? Weren't things getting tight?
I told them to arrange the pad frame so that the die would be 8.5 x 8.5 mm. That will be plenty big.
There is some analog involved in Ethernet. How will you solve the baseline wander issue?
Also how will you implement FCS (CRC checksum)? implemented as software instruction or transparently in HW?
It would be nice to have a custom integrated ethernet transceiver to allow deterministic and high bandwidth data transfer to another device (PC, tablet, raspberry pi, linux router, etc...)
Unlike USB, Ethernet is completely deterministic when sending/receiving UDP raw frames.
Ethernet is much more documented, and much more easier to develop SW for it. No driver needed. Almost every OS has a free ethernet driver (Even MSDOS with PKTDRV). And a wonderful and completely free ethernet analyzer called wireshark.
Also the propeller COG ram is 2K. A perfect match for the max 1500 bytes per frame used by Ethernet.
But the question arise and is still valid. There are multiple ethernet PHY ICs at around US $1 around ... does it make sense? I think It only will make sense if the functionality is seamlesly integrated into the IC. For someone that doesn't want to mess around with an external 48-LQFP ethernet PHY.
No need for Ethernet.
Seriously, Chip? I'm about ready to start eating QFNs if this goes on any longer!
Anybody who thinks this is a good idea will need to start fronting developer funds for NRE and placing scheduled orders for Propeller 2.
History can repeat itself again. When everything is going along swimmingly, we start to grow out of our pants again by adding things. Then we realize we're fat, go on a diet, and do the whole thing over again.
The best place for additional features are in future editions of the design.
Ken Gracey
It does seem like wireless is more and more in demand than hardwire.
So, I'd put wifi or blutooth as higher priority than 10base-T.
But, I also think we should stop piling on (right after USB, that is).
All right. Little Brother has spoken. No more dang features!
I would rate other things higher, and more P2 relevant.
Test USB first.
QuadSpi & dual QuadSpi == nibble / byte sync serial transfers
Upgrade serial that is there now, to fractional baud ( borrow from USB)
Fix for full bit length control
I think all of the above is planned already so are not new features, just fixes/ completion of what is there now
It's worth remembering the real deal will have more speed and room to do a lot in software. At any given time, we have a lot more than we think, just like P1 played out.
If "the ark" is a design goal, USB is a home run. Worth it.
"editions", plural, does this mean a P4 is on the horizon?
Well, I'm in the other camp. I see an industrial application where I would use the low levels of Ethernet for high speed one-way transport of data interleaved from 256 nodes. All time slots precisely predictable. No such thing as error correction or retransmission. Some low level hardware helpers would make that a lot easier.
To be clear, for this application I'm not wanting a proper full Ethernet function. Just a buffered Manchester link with CRC. Maybe some other goodies like a data comparator firing the interrupt.
But perhaps the pins can already do most of what I need.
Cheers,
Peter (pjv)
We need the silicon as soon as possible and no new features! More speed, more cogs, more memory. more pins. NOT MORE!
Would that be enough for your custom variant ?
What Data Speeds do you need ?
You can get 'high speed one-way transport of data interleaved from 256 nodes' from some simple serial-ring bus designs too, and P2 should be able to push Serial speeds to many tens of MBaud.
My needs are 100 megabits per second, continuously, no gaps, all day long. Totally predictable. Occasional communication errors are handled by ignoring the offending byte. Speed and reliability are utmost. I have been wanting to do this in a P1, but it needs some helper hardware such as an FPGA. I'm hoping the P2 with its smart pins can do this directly.
Cheers,
Peter (pjv)
However I'd really like to see the Prop 2 on my desk as soon as possible. I've been looking forward to this chip for years now.
if smartpins can handle 2bit data at 50MHz, RMII is only 7pins
And 125Mhz SMII only needs 4pins.
http://agata.pd.infn.it/LLP_Carrier/New_ATCA_Carrier_web/Appnotes_And_Reference_Designs/Zarlink_Application_Notes/ZLAN_86_AppNote_Jun06.pdf
But can it be done in two P2 pins, and what about base line wander correction etc.?
http://www.mouser.com/ProductDetail/Broadcom/BCM5241XA1KMLG/?qs=sGAEpiMZZMuXKgZRMPEonVeL2pirSPImaF1WlrMxhhU=
So you have 256 nodes, all sending ? No receive at all ?
How many bytes per node, and what BUS lengths ?
A ring bus is one way to reduce turn-around times & the address is implicit.
(and it is inherently duplex)
Yes, I had thought about using that approach, but that will have a SyncEngine limit of SysCLK/4, right ?
- means ~40 MHz on projected 160MHz silicon. (Assuming SW can keep up)
For custom-bus use, you could get quite a bit faster than 12MHz, but would still be short of 100MHz mentioned.
I think 100MHz needs nibble-transport at 25MHz approach ?
Ken said no! No, no, no! When Chip released the last FPGA image, I saw the light at the end of the tunnel! We just needed to test, find any issues, do a minor tweak if necessary. Before we even got half way, we were derailed by USB. And now, even before the USB stuff is available, we are are getting pushed even further off track with yet more change suggestions!
There will always be one more thing that it would be nice to have. I just want the one thing we should have already had: a finished Propeller 2. As the adage is sometimes stated, "perfect is the enemy of done!"
(As an aside, I admire @jmg's determination to get QSPI ("nibble-transport") implemented. Frankly, if we were going to get derailed by another new feature, QSPI would have been a much wiser choice than USB. USB, Ethernet, etc. already have a wealth of ICs available for implementing them as an add-on to a microcontroller. With 64 pins, the P2's best bet for supporting those sort of things is to support the I/O interfaces that those chips require: TTL serial, i2c, SPI, QSPI, 1-wire, etc.)
[/rant]
It may not make any sense to attempt this in smart pins because PINSETX and PINSETY take 18 clocks. PINGETZ takes 9..16 clocks. The nibble data would be faster than you could read and write it from the smart pin.
The best way to do this is in software, where you can grab a nibble every two clocks using straight-lined ROLNIB instructions for bursts, with the transition output mode of a smart pin generating the clock.
A FPGA built with that functional would let users experiment with things like Ethernet PHY connections,and of course all those QuadSPI Flash & RAM parts out there already
I didn't ask for USB to be so complex. Two simple instructions would have helped significantly.
IMHO Ethernet is being replaced by WiFi everywhere. I don't have any Ethernet here, only WiFi.
And WiFi modules are cheap as chips, so no, we don't want it inside P2 !!!
If there is any more die space, just fill it with more RAM. Personally I would like to see Cog#0 with more LUT space for cog-hubexec. Otherwise extend Hub RAM.
We need to get on with testing the P2 FPGA code. But it is still changing
BTW At the risk of bullets flying, I would rather see a P2 without smart pins (maybe 1MB Hub would fit???) tomorrow, than P2 with Smart Pins next week.
Besides, a lot more than we think will be possible with software and some external circuits.
No bullets. We can already have a P2 with smart pins tomorrow; it's the one we already have today. :P If one slight tweak was in order, it was to get rid of the state machines (though I'll miss them) and expand the serial configuration (which it seems Chip has already done?). Call it a day and be content.
Basically, Smart Pins has mostly stopped P2 testing for the past few months. Most of us are waiting for a stable FPGA release before jumping in to test.
If we just had to test the basic cpu and go, it would be quicker than adding the testing that will be required for smart pins. Realistically, there is no way the P2 will go to silicon with Smart Pins without quite thorough testing. Therefore, we could get real silicon much quicker without Smart Pins. BTW remember, nothing in this process with OnSemi has been proven.
So, if P2 went shortly (after testing the CPU), if the test silicon works, we have chips without Smart Pins. If it fails, we have had time to test out Smart Pins in parallel and they could be added for test silicon #2.
If I use P2 in a new product in place of the P1s I (manufacturers) could easily use 10k in the first run, but only if I have silicon.