Design lessons from the development of the YASEP architecture created Wed Aug 12 16:00:19 CEST 2009 by yg YASEP is the next major architecture that I design after F-CPU. I have learnt from F-CPU that some things work and others don't. This document discusses this issues and what YASEP teaches me too. First : KISS works. YASEP started under the name of "Very Simple Processor" with a limited set of features, a reduced performance goal etc. F-CPU wanted to be competitive with an already long-established architecture, its development tools, its commercial industrial environment... And it's not easy to be all that at the same time. Why does KISS work ? Because in the end, the design parameters must all be understood and managed by a single person. Don't count on anybody to do your work because you'll have to tidy up after him anyway. KISS means that the reach and goals are limited so the project's efforts are limited too, and have a higher chance to reach completion one day. So the definition of the goals is very important too because whatever we choose, one always has to reinvent the wheel and all the supporting stuffs behind. With YASEP, a lot of focus is on the development environment. The choice of JavaScript is very successful since the beginning, for so many reasons that I can't enumerate them. One of these reasons is the ease of alteration of architectural features : adding or removing an instruction is very easy. Supporting a new flag or form is quite easy too. Changing the whole instruction structure is more difficult and requires a lot of efforts. However, the cross-linking of the pages and the testbenches makes it far easier than with only paper-pen-brain : JavaScript pages catch inconsistencies faster and deeper than a human code review. YASEP also benefits from the "no hurry" approach : each small part is slowly developped and integrated, leaving room for code rewrite and enhancements. Some parts grow as needed, others don't change for years. I develop YASEP with many small touches here and there, the whole code is subject to change for any reason, at any time. There is no untouchable "golden code" because the code IS the definition and the definition evolves each time features are added or inconsistencies are found. So everything has to be modular, dynamic, useful, self-checking... and forgiving, because the code is often broken, so it should not break the whole system. Javascript can do that : it ignores a file when a syntax error exists, but it still allows the rest to work anyway. This gives the impression that some part is not here, and you only notice it when you know it should be there. But for the newcomers, it is less scary : it does not give the impression that "the whole thing is broken and will never recover". It's also good for the morale : there is less urge to fix or implement some little details, when a more important part requires a lot of work. The code will look as if it was working while in fact it is slightly impaired, but this won't distract from the more important work. This is why YASEP is in a "constantly broken state", I'm working on several things at the same time and care less for the details, while more important features are being developped. Besides "graceful failure", JavaScript is also ideal for many other reasons. PERL or Python are other famous scripting languages but they are not seamlessly integrated in documentation or webpages. JavaScript has a direct access to the browser's display and features. JavaScript also requires no development toolkit, or the installation of client-side software : Java would provide no benefit. And it is mostly platform-agnostic. My focus has shifted from "doing a CPU" to "working everyday to reinforce the code and think about new features". I don't hesitate to break things because the code is modular. The earlier I break stuff, the easier it is, because things are less definitive. I also think more about YASEP as a framework than as a CPU, because the framework helps define the CPU, which evolves too much (and easier thanks to the framework). The ability to easily test or try ideas is also very important as it helps categorize them, so YASEP can evolve faster. 2009-08-23 The availability of a design tool (the Actel toolsuite) and real hardware is also a big difference with F-CPU. F-CPU was to be "free" so no choice and investment could be done. I have chosen Actel and since then, I have a platform and an architecture that YASEP should match. idea => pen&paper => draft on computer (doc) => simulator => synthesis/P&R => working prototype All these things are necessary, otherwise it's not possible to go back and correct the design. If there is no synthesis or real HW behind, there is no way to close the design enhancement loop. This is one of the things that have held F-CPU back. 2009-09-02 keep the pages small so i will not fear to update them... and grep is our friend ! and the smaller the original goal, the more chances it will have to evolve and find some use.