P2 documentation
Peter Jakacki
Posts: 10,193
Hi Chip, as you know I've been making up a chip style block diagram and I hope to expand upon that and also include detailed smartpin diagrams etc. But what is missing is something simple like a one or two page shortform datasheet. Just enough to whet the appetite and give a quick overview. Like the block diagram, I've also taken the liberty of massaging some of your information from your P2 documentation into a single page with the block diagram to give you a rough idea of what it could look like. The shortform is easy to print out and I've exercised my preference for data sheets to be in landscape mode to suit monitors (I hate having to scroll just to finish reading a page) plus they format nicely onto a double-sided sheet when you have two pages. What do you think?
I'm doing up a pinout and package section as well which could probably go onto page 2.
EDIT: I've deleted the pdf I originally attached and added "UNOFFICIAL" to it plus I might add other watermarks since this is only meant to be a proof.
Here's a Dropbox link to the most current.
I'm doing up a pinout and package section as well which could probably go onto page 2.
EDIT: I've deleted the pdf I originally attached and added "UNOFFICIAL" to it plus I might add other watermarks since this is only meant to be a proof.
Here's a Dropbox link to the most current.
Comments
That is a very nice Preliminary Data Sheet.
Looking forward to the official data sheet.
Sorry, totally unofficial, but something for my own reference at least
I'm onto the second page with pinouts and mechanicals etc but you will have to look in my dropbox for the latest.
...or are we still waiting for the sample chips to know?
J
It is going to be 180MHz, worst case. OnSemi will run some tests to find out what Fmax will be at different process corners.
"P2X8C4M64P OctaCore Realtime ProcessorPreliminary Shortform Data" to
"P2X8C4M64P OctaCore Realtime Processor Preliminary Shortform Data 5/31/18"
That way when we come across 5 versions of this thing in a directory, all with cryptic file names like P2SHOR~1.pdf we can tell which ones are which.
Thanks for the effort BTW, Ive been looking for something exactly like that.
I at least now have a "data sheet" that I can reference easily and to which I will add more detail and polish as I go
btw - Only once I had made up the block diagram did some of the P2 information actually click with me, like the 4 DACs per cog!
Ah, there it is, in my original post, I did say "to give you a rough idea"
I know Chip is still busy with OnSemi so he doesn't have time to do this yet.
We can have a discussion about cogs vs cores etc later. For now we all know what that is.
Maybe even put the date in ISO 8601 format, so that we can accurately parse dates. I know that this format is only 30 years old, so it might not have caught on yet ;-)
While North America might represent June 1st as 6/1/18, there are enough countries that represent it as 1/6/18 to make it unclear.
Meanwhile 2018-06-01 is unambiguous for those who know the standard, and different enough from the competing "standards" to get people thinking.
I just changed the Google Doc to use this date format. I agree it is much better.
Or just 1515196800, if you want to be totally unambiguous an all.
Those VIO_0_3 type pins are all 3.3V, exclusively. They won't work well, at all, under 1.8V.
For the 'description' fields on the pins, it would be good to call out the SPI, SD, and serial pins as 'boot function', or something. The last thing we want to suggest is that certain pins are only useful for certain functions. Most everyone is acquainted with that kind of mess.
It's kinda pleasing to have this info printed up like this for internal reference plus I will be laying out PCBs in preparation for P2 chips. If P2 works, then I immediately have PCBs to try it out on but if not, they are only PCBs.
True, but thankfully there seems to be a growing choice at the 3v3 level.
The new Cypress Flash, and latest ISSI SRAM, both offer 3v3 part codes.
We used YYMMDD in the early 70's in databases (files in those days) to avoid any ambiguities and it made for a quicker sort on dates by being able to sort on a 6 character (digit) field. Alas, it wasn't 2K compliant, although you could use a quirk of the machine to use ":" as "10" permitting it to be compliant until Y21K.
Postedit Actually the quirk worked all the way to "?" so it could have been compliant until Y26K
I presume that's a time_t, in which case no, it's not totally unambiguous. What time scale is it using? TAI? UTC? Does it ignore leap seconds? The POSIX committee made a total hash of time_t by requiring POSIX conformant systems to pretend that leap seconds don't exist. Since leap seconds do in fact exist this has caused a number of competing, incompatible work-arounds to the problem to develop.
TImekeeping is hard
But with the different time zones it would certainly help if in addition to that they just used a single character suffix from A to Z that was weighted against UTC so that A = -11 and UTC = L and Z = +14. Here with AEST the code would be V but L.A. would be E
BTW, I'm taking a little rest from documentation and artwork and getting back into doing a ROM to suit DE0-NAN0 and BeMicro A2 as well as a serial/SD loadable version of the latest TAQOZ.
Is there just sort of a simple loader?
I picked up a Nano a while ago on Ebay - but it looked so much effort to start that I did not even unwrap it ...
So I could run Tachyon-P2 on it?
The French tried decimal time in the 1790's and again in the 1890's; It never stuck for long except in Astronomy. The Chinese used decimal time for a few millennia, but dropped it after the Jesuits came to visit in the 17th century.
If you are going to use letter suffices you'd be better served to follow the military, with A as +1, Y as -1, and Z as GMT (or UTC). Of course you also need to account for fractional time zones like UTC+09:30 which in military parlance is I/K.
My personal favourite fractional time zone is ACWST which is UTC+08:45; Good luck representing that with letters.
At least you used to be able to when it was still Altera
When Chip says he'll Skype at 10,000 we know that it will be 10,000 here too
The scientists are working on altering the Earths revolution around the sun. It's a big job, and they haven't quite figured if it's easier to slow it down to 100 days or speed it up to 1000 days.
They may also need to tweek the revolution to be precise so we don't have to add any leap days/years or leap seconds
Thats whats great about Unix time stamps, totally unambiguous. The epoch is Jan 1, 1970 UTC. The time elapsed since that date is the same no matter how you tell time locally. Unless your accelerating,or far away, or moving. Then you start having problems..
https://zachholman.com/talk/utc-is-enough-for-everyone-right
I don't think you read my answer carefully. I am aware of how Unix time stamps work. They are in fact ambiguous. They're defined as 86400 * the number of days since Jan. 1, 1970 UTC, plus the number of seconds elapsed during the present day, and hence are ill defined around leap seconds. *If* they actually were a count of elapsed seconds since the epoch then they would be unambiguous (given suitable definitions of epoch and of seconds). To quote from the open group standard (section 4.16, "Seconds Since the Epoch"):
I.e. there are places where the POSIX timestamps are "implementation defined", which is to say ambiguous. To quote an example from Wikipedia:
Sorry to go on at length, but this was an area that the POSIX committee got spectacularly wrong, and it's compounded by the folk wisdom that time_t timestamps are a count of seconds since the epoch. They are very explicitly not, the POSIX standard gives the (ambiguous) formula for them, and pretty much all Linux and Unix systems have followed that standard. There are a few systems that use TAI instead of UTC as their time base (see Wikipedia for the discussion) and those are non-standard-conforming but at least do have the property that their timestamps count seconds since the epoch, and hence are continuous and well-defined.