Propeller Datapath Available?

SRLM

I'm taking an introductory computer architecture course at my university and we're working with a (simulated) microprocessor called the LC-3. We've gone through every aspect of the design from the transistor up to assembly programming. I've particularly enjoyed the section where we trace the instruction paths for the various assembly commands. What I was wondering is if there is an available datapath sheet for the Propeller? I'm sure that there must be one, my concern being that it may be considered property of Parallax.

In case the terminology differs, here is what the LC-3 datapath is like: www.liafa.jussieu.fr/~carton/Enseignement/Architecture/Cours/LC3/datapath.png

Is there anything similar for the Propeller?

Mike Green

I've never see anything of that level of detail on the Propeller and I assume it would be proprietary to Parallax.

heater

Presumably one could infer a data path for the Propeller from it's instruction set and the available published information regarding timing, hub operation etc.

Jazzed has exactly such a project going on here:
http://forums.parallax.com/showthread.php?p=807328

Although it seem he does not want to publish the resulting Verilog.

Nutson also has an FPGA COG project here:

http://forums.parallax.com/showthread.php?p=762775

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon

Another controller I use has a "Timing Analysis Tool" that takes an application and gives timings for all the paths through the program, including the inter-core and inter-chip comms links. It's written in Java and the source code will be available. It could conceivably be ported to the Propeller.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 6/1/2009 7:52:26 AM GMT

heater

Yes but Leon I think SRLM is referring to hardware data paths within the CPU architecture. See his attached example.

Now timing analysis of pathways through software is also interesting. I thought that in general this was an unsolvable problem. The Halting Problem and all that.

The only time I have ever seen and used such a tool was for aircraft control systems that were written in a language called LUCOL. They could do it there because Lucol did not have any loop constructs. No way to create a loop in a module at all, no GOTO etc. So all the pathways through the code were easily discovered and a cycle accurate report of execution time could be produced on every compilation.

If your code has loops it's hard. I imagine that if your code is self modifying as is essential for PASM applications its pretty much impossible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon

It's actually dealing with hardware and software.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle