P2 documentation

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.

It ain't finished until it's finished. Along with the block diagram I cobbled this together late yesterday even mainly for myself. Little details such as proper headers and footers are the norm when it comes time to polish the chrome, but why waste time polishing chrome if it is to be changed or even scrapped and besides the time was spent on substance first. Be assured that if I publish a final that the chrome will be polished good n proper.

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"

The practice of writing a date as June 1st, 2018 is not a problem at all, it is when is shortened to 6/1/18 that it is confusing and no longer makes sense considering that larger numbers should mean later dates, except they don't always. All my date codes might not use the century but they at least go YYMMDD-HHMM so that numerical order = chronological order. North America still hasn't caught up with the rest of the world in that it still use ounces and pounds and inches and feet, and non-numerically ordered dates. I don't see the sense either in the English dd/mm/yy when time is hh:mm:ss except when they used to write "On the first day of the sixth month in the year of our Lord 2,018"

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.

There are some chips, even SPI Flash, which are designed to operate at 1.8V and where even 3.3V is too high. I was thinking that maybe the boot pins might be run at 1.8 or 2.5V. As for the description field that is more of a note field at the moment I guess but if you don't mind this unofficial document being a little more semi-official, then I can certainly bring it up to spec for that.

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.

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.

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.

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

Meanwhile 2018-06-01 is unambiguous for those who know the standard, and different enough from the competing "standards" to get people thinking.

Or just 1515196800, if you want to be totally unambiguous an all.

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.

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.

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.

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

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.

... doing a ROM to suit DE0-NAN0 ... as well as a serial/SD loadable version of the latest TAQOZ.

is there a simple fast way to get the image into the DE0-Nano without installing a Gigabyte FPGA suite?
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?

Of course since TAQOZ was designed with a small memory footprint to work out of a single cog and it uses interrupts for serial buffering. AFAIK you need to download QUARTUS but downloading is not like pedaling uphill, you only have to set it in motion and come back later. Don't think of how much effort it takes, if you do that you would hardly get out of bed in the morning. Just go through the steps and before you know it you will be empowered and glad of it. Remember, no effort, no joy!

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.

Sorry, you don't have the right version of decimal time. This one only has a single world, or should I say Earth, time. No zones. We just start work at different times around the world.
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

Meanwhile 2018-06-01 is unambiguous for those who know the standard, and different enough from the competing "standards" to get people thinking.

Or just 1515196800, if you want to be totally unambiguous an all.

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

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..

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

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.

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"):

The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.

How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.

I.e. there are places where the POSIX timestamps are "implementation defined", which is to say ambiguous. To quote an example from Wikipedia:

The Unix time number 915148800.50 is thus ambiguous: it can refer either to the instant in the middle of the leap second, or to the instant one second later, half a second after midnight UTC.

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.