GPIO Slice / Port Mapping Confirmation Square 4D0

[JasonWhiteman]

Although I could trace through the schematics - I'm moving on to using a different port so I'll instead roll on to changing ports and ask the question of the forum:

The documentation XA-SK-GPIO-hwguide_GPIO_Slice.pdf shows the following port mapping for "Square":

[...]
GPI_0 4D0 GP Input
GPI_1 4D0 GP Input
GPI_2 4D0 GP Input
GPI_3 4D0 GP Input
[...]

Contrast this with "Star" that shows 4D[0..3] for GPI_[0..3] -- which would be a better story than 4 pads shorted to the same GPI buffer.

Is this (the square mapping) a typo, or correct?

Prelim research: searched for "4D0" in forums - not found.

Regards,
Jason Whiteman

[EdB]

Hi Jason,

It looks like that is a typo in the documentation. It should be 4D0 to 4D4.

I will raise a bug against the document.

Ed

[JasonWhiteman]

Always happy to hear swift action taken to identified errors. Glad I could help future engineers see corrected documentation to guide their port selection and coding.

Of course, once an error is identified (and while we're at it) - it helps to "regression test" the rest of the documentation (items we feel are correct because no problem was identified). Hopefully no other issue will show up - but maybe something will.

Regards,
Jason Whiteman

[Bob]

..found it better to rely on 'raw' portmapping rather than macros in <platform.h>.
P becomes XS1_PORT_
The appended 1/4/8 etc become portwidth and followed by location in hardware mapping. The 1/4/8/32 bit ports can though overlap so care is needed in design. (..we need more 1bit ports in future silicon design or ways to remap them without multiplexing).
Last digit is just the suited port in/out variable mapping.
Nothing more to bother with or question in this context.

[JasonWhiteman]

Thanks Bob. Just to clarify for future readers of the thread: my question is not related to any software paradigm (port assignment in XC/etc) per say. The question was directed around the hardware connections of a particular hardware implementation. Namely, the XP-SKC-L2 "core board" that comes with XMOS's SliceKit. ... and how those connections are documented.

The observation was that documentation (now confirmed) incorrectly shows hardware connecting the same XMOS buffer to multiple pins of the "square" port PCI-E type connector.

Further research has confirmed the documentation error - and something is being done to fix the docs. All is good.

How to deal with port assignments in software is a different subject.

In the usage model of utilizing a dev kit to start a prototype design, I'm going to be looking at documentation to determine how the dev kit elected to "bring out" I/O ports of the microprocessor, architect my connections according to the docs (usually schematics, but will use summary docs - if available - as the one called out in this thread), and then as a 3rd step deal with the software/firmware implementation steps.

Regards,
Jason Whiteman

[Bob]

..life has eventually taught me Jason, that venturing near any dev kit from any mfr needs a descent multichannel scope that can probe pins, intermediate chips and connectors. This is essential if you are basing a product design around it I have found.

In relation to port allocation & mapping/timing then check out the post 'Sample,sample,sample' in the processor section. Leli makes some very useful contribution here. Believe you will need to include some inline assembler in the .xc code to do these things.

I like the devboard approach but you must be very cautious if you are involving precision analogue circuitry;layout, signal routing decoupling and supply impedance all need due detail attention.

[JasonWhiteman]

Thanks Bob.

We're on the same page. My post is just pointing out an error in the documentation that can throw someone else off who believes the docs. Since I solved my problem another / faster way - I no longer needed to do the grunt work of tracing through the design myself.

I've got scopes and have been using them in favor of the timing simulator because it's faster for me to fire up the Tektronix and measure than it is to fool with the tools. Haven't had a logic analyzer type issue yet. Next rev changes technology so I may need to use the LA - but generally favor the scope to watch the edges anyhow.

Haven't asked a timing question in this post that I'm aware of - but I did read the sample^3 post. Maybe you're crossing posts since some of my other posts are less "surface" and more "meat" questions.

All of that said - I think I've navigated through some of the early gotchas without having to go inline.

I believe XMOS is working the documentation issue hilighted in this original post and is launching a new version of the documentation soon if they haven't already. "Case closed".

That said - certainly value the philosophy -- even more since it's design philosophy I share.

Regards,
Jason Whiteman

[Bob]

Jason, would you believe that here in the uk, few embedded software engineers even know how to set up a trigger for a scope. It is even worse than this though, because there is now an established tradition of using uml class design for embedded systems(..as taught in academia/higher education). They then code it in c++ which is not even an object language; just a way of producing libraries of reusable code.. (as Bjarne Stroustrop intended), they also have an implicit belief that they can code their way out of anything (without understanding the cause), and if not then they need a much bigger processor.
A couple of decades ago I put together a ride control system for hovercraft based on three 4MHz clocked 8bit Z80s. It was modelbased control, adaptive, realtime monitoring and logging. Now I find that find that a meeting and several is needed because there are troubles controlling a few stepper motors using a recent Armcore..

I sent the reference to Leli's comment because I saw you had been involved in fpga design. Using 2ns delay resolution is I think pretty kool just using code change. Was info only.

C is not a good language when it involves concurrency, multithreading. interrupts, semaphores; it is an arcane and specialist language anyway. It requires libraries, arcane macros and language extensions(xc changes being an relevant example). Niklaus Wirth's more verbose Modula2 approached this. Transputer Occam was good, took me 4 hours to learn it(..plus three hours to install the dev environment) and then I was doing real work with five processors and some transputer parts (immersed) doing precision measurement in liquid nitrogen, within a few weeks, hardware, sensor and software development.
Clumsy C linear thinking destroyed the transputer because the fraternity could not cope with detail parallelism;you need an os to do this for you. Now similar thinking appears to be stopping xmos acceptance despite adopting C (related) coding.

To those of us from outside of of electronics and software education formal backgrounds, then C is more arcane than assembler.. C was after all just intended as a higher level assembler.

Should you wish to collaborate on some ventures then I'd be happy to work with you. My background is dynamics and control for highly nonlinear systems and systems needing robustness in uncertainty.