YASEP news

I have not been fully satisfied by all the boards that I have seen. There are always details that don't match a project or requirements that are not met (size, price, features, whatever). So I finally decided to start my own board(s).

It seems that YASEP could easily replace microcontrollers that I already use. The flexibility offered by FPGAs and the ability to strip a thing down to the minimum, then expand on that depending on the needs, makes this solution more and more attractive. No difficult selection of features and package (as with fixed-function chips), put the FPGA on the board and route the pins...

I can't solder BGA package, or even build suitable PCBs myself, but I'm already able to make double-sided PCBs that can be fitted with a FPGA in 100, 144 or 208 pin in QFP package. I'll be able to reuse these designs in the future, or make my own cheap modules.

I wish it could stabilize soon, but at least movement is a sign of activity (or the reverse :-))

I was annoyed by the ASU operations :

  ADD, SUB, ADDS1, SUBS1, ADDS2, SUBS2, MIN, MAX

These instructions were the last ones that used skip technique, since it is progressively dropped in favor of relative branches by conditional add/sub to the PC register.

How is it possible to provide the same functionality without skip ? It's the same old question that decades of research has not yet answered definitively. The Carry Flag is the obvious solution but I have just dropped the "status/mode register" in favor of another general purpose register. So where can I find a stupid bit of room ?

The answer is there under my eyes : the LSB of the PC ...

OK OK I know it's ugly. But consider these aspects :

• The PC points to the next instruction and never uses the LSB because all the YASEP instructions are aligned on 2-bytes boundaries.

• Any write to the PC register modifies the bits 1 to 31. Bit 0 comes from the ASU's carry output.

• We can declare that only the ASU operations (or context changes) can change the PC's LSB. All the other instructions can read it and test it, so the informations is easily available.

• Since we dropped the 4 instructions that used skip, these "slots" can be filled by other instructions :

 CMPS, CMPU, SMIN, SMAX

CMPx are just like SUB but don't write the result back. I wish it could set the LSB of any register but the current architecture doesn't allow this, so please keep the destination field to PC when encoding the assembly instruction.

3 new instructions deal with signed comparison : CMPS, SMIN & SMAX. They were missing from the previous opcode maps but the elimination of the skip-instructions leaves enough room. I have to update the VHDL now...

• Keeping the carry bit in the LSB of the PC can have a curious side effect : relative jumps with odd values will make the carry bit ripple to the other bits of the result, so the destination address that is written in the PC will depend on the value of the carry bit. In practice, there is no speed or size advantage (compared to condition codes in the new opcode extension) but the possibility is there...

• Clearing the carry flag is done with

  CMP Rx, Rx

• Setting the carry flag is done with

  CMP -1, Rx

(or something like that)

Usually, I would end the post with something along the lines of "this is good and everybody is happy". Now, I feel a bit disapointed that YASEP looks more like other architectures, and has less distinguishing features. It is less groundbreaking and it will have to face the same problems as the others, on top of its inherent quirks. But it's still better than nothing and I do my best to keep the system rather coherent and orthogonal.

So I've been busy again...

This time, it's all about JavaScript. The preliminary version is available from http://yasep.org/~whygee/listed/listed.html

What is it really ? It's an interactive assembler in dynamic HTML, loaded with JavaScript and CSS stuff. It's also an interface to the JavaScript assembler and the simulator.

• The little windowing system allows one to break a whole program into small chunks, that are easier to manage. Assembly langage listings can easily get messy, but local symbols and hideable sections reduce the usual clutter on one's window/screen.

• As the user edits each line, the modifications are committed to the rest of the page : the instructions are re-assembled, the labels are updated where they are used, the simulator can reinterpret the sequence and give preliminary results for given testcases...

• The assembler is not limited to YASEP : the CPU interface is going to be generic, and LISTED could support any CPU that can be described in JavaScript (that means : all, provided enough adaptations are coded). A dummy, overly simple and dumb CPU architecture will be given as an example, so somebody can easily adapt it for x86, PIC, Alpha, MIPS, POWER, or RCA1802 ...

• This is going to be linked directly with ARF, which is another graphic coding interface.

I have been working on this for more than 3 weeks and a lot of work still remains. I focus on user comfort and UI design but I keep flexibility and expandability in mind. For example, I have developped YGWM to handle the windowing part, which will be reused by the whole yasep.org website. The assembler and simulator will remain completely decoupled.

In the end, it only confirms what I believed for some time : JavaScript is a fantastic opportunity for really new ideas, it provides portability and rapid design. However, after trying to make it compatible with different browsers, my strong recommendation is : use Firefox and stick to it

As you may know, YASEP16 will probably be used in my girlfriend's "pet projet" Ours Agile. This involves lots of real-time computations, countless sensors and more than 30 actuators... Sure, YASEP could handle that, probably. But the interfacing was giving me headaches, so many analog components (on top of high-speed memory) seems expensive and/or difficult.

Then I spotted a second-hand AFS600 evaluation kit from Actel, that I got for a fair price. It was a bit risky and I first thought it was broken. But since it's 2nd hand, somebody has probably played with it, and just uploaded a new configuration bitstream. With the help of a french rep., I found and uploaded the original demo bitstream and ... Magic happens !

This FPGA family comes at "premium price" but it's a damn great opportunity for robotics projects :

• 512KB of program space as Flash EEPROM (no need to download from external SPI !)

• onchip 100MHz RC clock generator (exactly what I'm aiming at !)

• RTC, temperature sensors, low power...

• high-speed 30-channel ADC !

• several integrated MOSFET gate drivers

• 13K tiles vs 6K on the A3P250

• 24 SRAM blocks vs 8 on the A3P250

This is definitely a great toy for robots...

Hello and Happy New Year Everybody !

I took some time to work on the next major building block of the YASEP16 execution unit : the shift/rotate unit is now ready in 16-bit flavour.

I concentrate now on YASEP16 because it is smaller and marginally faster, and consumes less bandwidth. It can fit easily in the A3P250 and its 6K 3-input tiles, though i don't know how many tiles are needed in the end.

SHL_16 uses about 220 tiles, and Actel's place&route estimates the unit to run at 140MHz in pipelined version. This is slightly faster and smaller than ASU_ROP2 that performs Add/Sub and boolean operations (115 MHz and about 350 tiles). The overall ALU (ASU_ROP2 + SHL + IE) is going to take roughly 700 tiles, or 1/8th of the A3P250's surface. Speed is looking satisfying, as I intend to clock the thing at 96MHz on the ACME boards (64MHz * 1.5 with the PLL).

Overall, the following operations are ready for the 16-bit flavor :

• ASU : ADD, SUB and compares as side effects.
• ROP2 : AND/OR/XOR/NAND/NOR/XNOR/ANDN/ORN as well as comparison for equality (XOR followed by a OR reduction tree)
• SHL : SHR/SHL/ROR/ROL/SAR

The next part to be developped is the IE (Insert/Extract) unit, for the load and stores of bytes into a half-word. Stay tuned...

''Note : some P&R runs give a bit higher working frequencies but I reserve 15 or 20% of margin, since I expect that all the units put together will need even more MUX2 all over the place, longer wires etc. resulting in slower operation.' Furthermore, it is only YASEP16 yet, and the 32-bit flavor will double the design's size... '

I recently got 3 colibri boards ! When you think about Italy, you think Ferrari and other excellent things, now I'll also think prototyping boards

Thanks to ACME systems, I bought 2* A3P250 and one A3P1000 boards for a friendly price. These are pre-series units and may slightly differ from later versions, but they are really as cool as the pictures let you think.

The website is also updated : the JavaScript engine is now mostly functional for YASEP16 and YASEP32 versions. The documentation is not updated and many dark corners remain in the architecture definition. I have chosen to publish the latest versions, since I don't know when I'll do this next time.

Recently, I have finally chosen the licence for the YASEP project : it's the Affero GPL as published by the Free Software Foundation.

It is practically the same as the GNU GPL but with one interesting twist : You have to provide all the (derived) source code if you use it on a server.

For the YASEP project, it's not a problem because all the "intelligence" is provided by client-side JavaScript code, and the rest is static or dynamic HTML (not server-generated pages). However, using the AGPL is a clear sign that YASEP is not just a bunch of RTL files packed with documentation pages. It is a living, dynamic, organic set of files that interact with each others...

Also, I would like that eventual contributors keep the structure of the files and directories, so the whole archive remains available to anyone visiting the sites. YASEP directly provides the link to the current archive on the main page, and I believe that this is a good thing that others will do in the future.

Concerning the VHDL source code : since the only difference between AGPL and GPL is the server clause, well, I distribute the RTL files with AGPL too. One licence to rule them all...

I got a nice contact with the Open Graphics project :

http://www.traversaltech.com/store.phtml

http://www.opengraphics.org

http://www.openhardwarefoundation.org

They need more than 40 preorders before then can do the first batch of boards ! With the biiiig FPGA on this, helped with the fat and fast SDRAM, it's not just a good candidate for a graphics card, it's a dream for CPU designers !! And look at those nice extension connectors...

It's going to cost roughly $1500. If I had the money, I'd buy it right away. However I'm broke AND the free Xilinx software tools don't seem to work for this large FPGA. Again, I'll have to do what I have done during years : wait...

So I've been busy.

I've spent most of the summer developping YASEP and now I'm almost broke, so I'm hunting more "mundane" activities (of the kind that will maybe help feed my geekette and myself).

Fortunately, before I blew up my savings, I was able to buy toys that will be useful "in the future", like those über-sexy 4Mx36bit synchronous static SRAMs that clock at 225MHz (unfortunately, available only in BGA, but I've grown up recently)...

But seriously, I'm stuck

I would LOVE to spend all my time developping YASEP, because... well it's so easy now, and everything is coming together at last ! I would just think about it, hack a bit more and get new results... Furthermore, I receive some very positive feedbacks now, particularly from ACME systems. Their new FPGA board (called COLIBRI and equiped with a A3P1000) is almost ideal for a 32-bit YASEP ! I can even swap the 12ns SRAM with 8ns versions and get a boost from 66MHz to 100MHz...

As a side note, I have just found how to integrate the UMIN/UMAX instructions in the FPGA implementation, without bloating the pipeline.

So I'm OK but it could be much better, in a less material and pragmatic world

PS : Not everything is bleak : after last year's breathtaking series of concerts, I jumped in Satine's new project Satine ünder philharmonëën' wich involves 40 classic musicians. I'll add LED lights all over the stage !

Look at the singer in this video : Mia wears a blinking LED earring that I designed especially for her last year. If you're interested by a custom version, don't hesitate to ask me !

I know, it's not related directly to CPU design, but the new jewel I'm preparing will have 8 cores...

The architecture of YASEP is very unorthodox. It is a living experiment and evolves in many unexpected directions.

However, one known uncertainty has always been how to implement the instruction fetch mechanisms. The memory queues have been a guideline but no organisation has been tested yet, and validated. Back when VSP emerged from the chaos of my brain, I wanted to use one of four queues to fetch instructions, and to indicate the current queue in the 2-bit CQ register. This idea was already implemented in the RCA1802 processor (the 4-bit P register) but this adds some overhead (and YASEP's instruction stream was never meant to be ultracompact).

Funny : I find more and more common traits between YASEP and 1802

The CQ register (just like the COSMAC's P register) also slows down the core as a whole cycle is necessary to fetch the opcode from the queue. This goes against the idea of a pipelined processor, the pipeline being the implementation of a sequential principle and sequence occurs a lot in an instruction flow.

However, the availability of several queues as potential pre-cooked jump destination (address as well as corresponding data) is very interesting and this remains in the YASEP architecture. A jump instruction with a direct immediate adress remains possible but with some (future and planned) architectures, there is the risk of a high execution latency.

I recently came to the conclusion that a compromise between the completely weird and the classical approaches is necessary.

So I keep the memory queues but the first one is modified and assigned to the instruction pointer and a status register. I had sworn that I would never do that, but I'm forced to admit that in a sense, and in the current situation (where no cache can support parallel memory accesses) something "looking like that" is necessary. And I'll do my best to avoid the inherent traps !

First, why do I need the registers #0 and #1 to hold these values ? In the currently planned first implementation, I can use a bank of 512 registers, or 32 banks of 16 registers. This means that context swapping can be very fast (1 major cycle) and I need to save many informations at once. If these informations are stored in the SR space (as previously planned), more cycles are needed to save/restore the "whole" context. So the best place to store these critical informations is in the register set itself. I could have chosen to create another parallel register bank but this would consume too much memory. The availability of the "Current/Next IP" is also very useful for computing addresses in position-independent code.

So the new register map is :

0h: IP (replaces A0)
1h: ST (replaces D0)
2h: A1 \ Q1
3h: D1 /
4h: A2 \ Q2
5h: D2 /
6h: A3 \ Q3 
7h: D3 /
8h: A3 \ Q4
9h: D3 /
Ah: A3 \ Q5 
Bh: D3 /
Ch: R0
Dh: R1
Eh: R2
Fh: R3

Second: what does the Status Register contain ? Of course, I avoid the storage of carry flags and such. But I can't avoid the auto-update bits of the 5 remaining queues. They use 2x5 bits and 6 bits are unaffected yet (for how long ?). These two bits per queue represent the following codes :

00 : no update
10 : post-incrementation
11 : post-decrementation

2 queues are able to implement a normal stack (LIFO) and 2 additional bits represent this ability. So Q4 and Q5 have the following properties in the Status Register:

bit N   : update on/off
bit N+1 : update up/down
bit N+2 : stack on/off (pre/post modification)

Third: These registers are not really real registers. These are "shadowed" registers with a physical instance copied somewhere else. This is necessary because the register set can't have enough ports and these 2 specific registers are critical and accessed every cycle . So their incorporation in the register map makes them easily remanent through context switches and IRQs, as well as easily alterable (without going through get/put instructions) but the register bank is updated only when these new registers are accessed. Some new datapaths must be reserved for them.

sigh...

This means that most of the opcode map (the part with the jump instructions) must be redesigned.

re-sigh...