Xena

AmigaOne X1000 platform specific issues.
User avatar
ddni
Posts: 230
Joined: Fri Dec 02, 2011 11:06 pm

Re: Xena

Post by ddni »

I don't think that you are being at all negative.
The lack of any real utilisation of Xena, coupled with no real discussion about why it is on the motherboards, leads to valid questions being asked.
User avatar
mechanic
Posts: 510
Joined: Sat Jun 25, 2011 9:22 pm

Re: Xena

Post by mechanic »

@ddni
You are correct.

@jaokim

There are real ways of moving useful data around, but you're right,,,it takes a solder iron and a useable prototyping board to put some chips on, and there is no board available. There are also no PCIe full serial or parallel ports available.

The Raspberry integrated into the xorro slot is cool. Could do a lot with that. I was going to use a BeagleBoard with most data going thru the Ethernet and xena for control of the system, but after waiting 3 1/2 to 4 years for something to happen from the powers that be I just gave up and moved along.

Such is life.... Bummer.
A-Eon A1X1000 ATI HD6850, Creative SB1570 PCIe, RTL8139 net PCI.
User avatar
ddni
Posts: 230
Joined: Fri Dec 02, 2011 11:06 pm

Re: Xena

Post by ddni »

You'd need to be a brave man or an electronics uber guru to risk plugging a homebrew board into an irreplaceable Nemo motherboard....
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 525
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: Xena

Post by LyleHaze »

Just a few random notes,

Yes, it could have been many things, but nothing so far of much interest.
The poor performance of the localbus interface was a grave discovery. I hated having to deliver that news to Trevor. It's as close to "break my heart" as the Amiga experience has ever done to me.

I am cautiously optimistic about the improvements to the X5000 localbus interface. It looks real good on paper, both the improvements to the original interface and the new options being offered. I don't own a X5000, and my personal time is not as available as it was when I worked out the X1000 stuff.. so if, when, what and who are all undecided at this point.

I did come up with a project that is workable on the X1000.. The Sentinel X-Logger uses the Xena chip to capture and store debug logs. And it's not limited in log length nor number of logs, within reason. thay are all stored on an SD card, and can be read back from the command line or you can remove the card and read it on anything..
OK, so it's not super-flashy or anything like that.. but it's beyond what can be done without a separate processor, so that's something.
And that extra header on the X5000 board should allow the same Sentinel to run MANY TIMES faster serially than is possible through a real serial port.

Another one caught my eye.. there are RGB (Red, Green Blue, mix for full color) LED strings that allow each LED to be addressed individually. Controlling these requires a VERY FAST clock. Nothing that multitasks can do this. But a Xena chip could do it easily. This would make "gee whiz" case modding a LOT of fun. Because Xena can do multiple outputs in paralell, this could even scale up to a small-ish graphics display.. And the improved interface of the X5000 would make getting the data into the Xena chip quite easy too.

As far as the "nervous" factor of soldering up your own stuff. I had picked up a few non-optical bi-directional level shifters that are fully isolated and as crazy-fast as the Xena IO. Using these as a "front line" would create a safety barrier. No part numbers in front of me right now, but I could look them up if asked.

Finally, I did not give detailed answers to some excellent questions because.. I have not played with this for a while, and I don't want to mis-remember anything.
I have a lot going on in my life right now, and I have not actively played with Xena for a while. I'm not being difficult, I'm just being careful to not give out wrong information.

Other opinions are welcome, you are free to disagree if you like. But I'm too tired to argue, you will win by default.

:)
User avatar
jaokim
Beta Tester
Beta Tester
Posts: 90
Joined: Sat Jun 18, 2011 12:41 am

Re: Xena

Post by jaokim »

Yeah, I really like the serial logger regarding its real world usability. But like you say, it ain't super flashy. A flashy LED thingie would be flashy, but less usable.
I have the prototype board, so I might solder something, although I'm a bit reluctant, and slow to start. Also thought of some spdif thingie that does cool stuff with sound, just because it doesn't require a lot of extra hardware, as it seems.

Again, regarding the localbus interface -- is it slow mainly because of having to synchronise, or is it an actual limitation of th hardware? I'm thinking: could I f.i. just send data from Nemo to Xena, without needing to wait 2 ticks (as I see in the code) in order for the data to be reliable?

Furthermore: besides the keepout part -- what are the real "dangers" when doing only software stuff? I sort of understand that setting pins as outputs from two ends can be bad, but I know too little to know when I might be doing that. Basically -- can I without knowing it, do "bad stuff"?
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 525
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: Xena

Post by LyleHaze »

I'll describe the issue as best I can without notes in front of me.
Please do me the favor of replying back with more questions if anything does not make 100% sense.

Also, since this is a hardware issue, I'm not sure exacly what level of comfort you might have with this,
More questions are always welcomed.. don't be aftraid to ask, on or off list as you wish.

When a bunch of peripherals share a common (parallell) bus, there is an understanding that only one device at a time will drive the bits of that bus. This is generally managed with an address decoder, which offers an "enable" signal to the addressed device, as well as a Read/Write bit, which indicates whether the peripheral is being talked to or read from.

So the "contract" is that you can drive the bus ONLY when you are being addressed AND you are being read from. at all other times you may READ the bus but not drive it. If two devices were to try and "drive" the bus at the same time, the result would be unpredictable, and possibly "bad" for the drivers that are wrestling for control.

This explanation is a bit simplified, but if what I wrote so far makes no sense, then the next part will only get worse..

Because the Xena chip has such a unique, flexible, and fast I/O structure, it was envisioned by the developers that it could interface DIRECTLY to the bus, doing it's own address decoding and all that "glue" logic.. Which would be a neat trick. It was designed with that in mind.

Now on to our specifics: The "fast localbus" multiplexes the high half of the address bus, the low half of the address bus, and the data bus on to one 16 bit wide group.
Sharing this bus are an FPGA. (I think), the Compact Flash socket, and the boot ROMs (2)..

There are pretty tight timing constraints when you see the address (in two parts) then respond IMMEDIATELY with a data read or write (if the address is yours).. but that's not where we tripped up.

This "localbus" is leading to a half-dozen devices, and the total capacitance is.. a bit more than I would have wished for (sorry, no technical data available, please bear with me).
This will work fine as long as the "bus drivers" on each of the attached devices is strong enough to drive the bus wires QUICKLY to their desired state..

But the output transistors on the Xena chip are not "bus drivers", and while they MIGHT have been strong enough in the original design, a process called "die shrink" is a normal part of a chips development, involving downsizing everything as much as possible to keep the chip affordable.

So the Xena can READ data from the localbus as fast as you might want to go, but WRITING from Xena to the PA6T takes WAY TOO LONG. The only way I could make it work at ALL was to go change the device timing settings to the slowest possible speeds, then cut the master clock to half speed.. then I could get data through, but it would be binary OR'ed with the last half of the address.. forcing even more wacky adjustments.

That's about as deep as I can go without finding my old notes.

The "keepout" section is what enables the Xena output buffers.. if left ON at the wrong time it may cause bus contention. (see above)


In an obvious effort to end on a brighter note:
The X5000 has a bigger PGA, which is now (in part) dedicated to buffering all the Xena bus signals.. Yippee!!
There is also a fair bit of what appears to be "dual port ram", so the Xena and the main processor can exchange data without needing to synchronize.
This should be quite exciting.

As I mentioned already: I'm fairly sure of this, but PLEASE ask questions if you want more detail.
And don't solder anything based only on my memory. :)

Closer to your question:
Some part of the program "sets up" the bus timing.. If you were to build a project where the Xena is written to, but never replies, you could alter that bus
timing considerably, and go really fast.. passing data IN TO Xena can be done quite fast and quite safely. no damage if it fails except possibly some garbled data.

I had never "played" with bus timing before this project. It's not difficult, but it did take me a little time to get my head wrapped around what was really happening.

You could probably "watch" other devices too.. Boot ROMs, Compact Flash.. All that data is flying right by the Xena chip.. Hmm..

If you're brave enough, mechanic has dug deeper than most on this thing. He does have an appreciation for the "bleeding edge" stuff. He scares me just a bit, but I say that with appreciation as well. ;)

As far as soldering goes.. Optical S/PDIF is optical.. so safe once the board is built.. MIDI IN is also optically isolated.. and I mentioned before that I have some chips (so far untested) that are Bi-directional, fully isolated, and also do voltage conversions too. a bit pricey, but everything you ever wanted in a Xena I/O buffer.

For those that are more timid, our favorite Amige dealer has my Xorro now, so they can get all the details from my build. They just might offer a build service if you ask for it..
and I have a few sticks of those addressable RGB LEDs, if I EVER get ahead of my other fourteen projects.


Peace,
Lyle
Last edited by LyleHaze on Tue Nov 22, 2016 2:00 am, edited 1 time in total.
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 525
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: Xena

Post by LyleHaze »

Postscript:
Our community has members across the spectrum in regards to programming experience, and also in regard to hardware knowledge.
I am NOT the smartest person in our group, and I will not pretend to be.

The previous post was written in an attempt to explain a problem in a way that a lay-person might be able to understand.
Whether or not I succeeded in that is open for debate.

It was NOT meant to describe the technical ability of jaokim, ddni, mechanic, or anyone else. I try to write for the wider audience that
is the Amiga community.

If the way I wrote it is too simple for anyone, then they are probably a bit more advanced than average.
If you're smart enough to point out errors in my post, you are WELCOMED and INVITED to post a more accurate description.

If you think I am completely off my rocker, then we have probably met personally already, because all my friends KNOW I am crazy.

I think that covers the basics, anyway.

LyleHaze
User avatar
Srtest
Posts: 240
Joined: Wed Jun 11, 2014 5:06 pm

Re: Xena

Post by Srtest »

LyleHaze wrote:Postscript:
Our community has members across the spectrum in regards to programming experience, and also in regard to hardware knowledge.
I am NOT the smartest person in our group, and I will not pretend to be.

The previous post was written in an attempt to explain a problem in a way that a lay-person might be able to understand.
Whether or not I succeeded in that is open for debate.

It was NOT meant to describe the technical ability of jaokim, ddni, mechanic, or anyone else. I try to write for the wider audience that
is the Amiga community.

If the way I wrote it is too simple for anyone, then they are probably a bit more advanced than average.
If you're smart enough to point out errors in my post, you are WELCOMED and INVITED to post a more accurate description.

If you think I am completely off my rocker, then we have probably met personally already, because all my friends KNOW I am crazy.

I think that covers the basics, anyway.

LyleHaze
Hi Lyle, just peeking in.

While I do feel comfortable talking about software concepts I wouldn't dare throwing myself here. What I can say is that Xena "place" is very intriguing for me. It also goes to show you that there are still creative ways to approach computing in this day and age of extremes between the totally market based approach and the technological fanatic/gadget based one. Reading this threat has been the first time I got a view in to what is a Xena (as a user of course) and while it doubled my curiosity it also made me more aware of that old Amiga gap between what is imagined and sometimes goes against the flow and what lies here in the X1k that have still yet to be utilised. That is not such a small merit as it's not about being smart and explaining everything it's sometimes more about raising levels of curiosity and engaging and that you have done well ;-)
User avatar
mechanic
Posts: 510
Joined: Sat Jun 25, 2011 9:22 pm

Re: Xena

Post by mechanic »

I have posted a Xena set of programs to wikisend. They will be available for 7 days. They are in a .zip file and named speed.zip
http://wikisend.com/download/321404/speed.zip

I do not recall if this set of programs were done with the thought of a card in the Xorro slot so just to be safe make sure the slot is empty.

If you understand C you can gleen some understanding from the programs. XC is a little different but not hard to come to grips with.

If you look at speedbus.c and compare my code with Lyle's Buffer example you will see the setup is different for the localbus, which is what makes Lyle think I'm scarey. Well, all I have to say to that is.......BOO!

The point of the program is simply to see how fast the localbus can do data transfers. Read the readme, ask questions.

Len
A-Eon A1X1000 ATI HD6850, Creative SB1570 PCIe, RTL8139 net PCI.
User avatar
Srtest
Posts: 240
Joined: Wed Jun 11, 2014 5:06 pm

Re: Xena

Post by Srtest »

mechanic wrote:I have posted a Xena set of programs to wikisend. They will be available for 7 days. They are in a .zip file and named speed.zip
http://wikisend.com/download/321404/speed.zip

I do not recall if this set of programs were done with the thought of a card in the Xorro slot so just to be safe make sure the slot is empty.

If you understand C you can gleen some understanding from the programs. XC is a little different but not hard to come to grips with.

If you look at speedbus.c and compare my code with Lyle's Buffer example you will see the setup is different for the localbus, which is what makes Lyle think I'm scarey. Well, all I have to say to that is.......BOO!

The point of the program is simply to see how fast the localbus can do data transfers. Read the readme, ask questions.

Len
Thanks, Len.

I have put quite a lot of thought into this which evidently is more about trying to say how I can't get it right now.

As a veteran user that grew up on Amiga I always tried to learn about what I was doing. That had really taken a momentum with me since I came back.

Recently on the aos forum I put a link in a discussion about file structure and the way newer file systems can interact with non-magnetic hard drives.
Where I sit, thinking about file and hard drive structures is more my cup of tea. Quite recently I read an article about aos4 memory system and had
all those thoughts about it while I couldn't put them into words even if you really wanted me to try.

All of that is just to say I'm not at a place where I can relate to what you are doing directly even if it does interest me. Right now my mind is taken
by file systems and memory... so for the time being I will put part of the log of the speed util I tested on the X1k.

________________
PLL setting (from XE):
sswitch reg 06 = 00002700
sswitch reg 08 = 00000004
system freq = 500.00MHz
Done!

Loops = 0x2710 FromXena 0x b3
Loops = 0x4e20 FromXena 0x b3
Loops = 0x7530 FromXena 0x b3
Loops = 0x9c40 FromXena 0x b3
Loops = 0xc350 FromXena 0x b3
Loops = 0xea60 FromXena 0x b3
Read/Write Loops done = 0xea60

Loops = 0xea60 = 120,000 data transfers
times 16bits/transfer = 1,920,000bits total.
________________

Shy.
Post Reply