ADD: SD/MMC interface for SCSI hard disc emulation.
ENH: FPU Overhaul. Pipelined operations.
ENH: PIPE5 fast stores.
And various tweaks here and there.
Fast stores for PIPE5
This is a small optimization for certain forms of the ST instructions which only need two register reads.
From the beginning, the FPU was meant to be pipelined. Floating point instructions already lasted several cycles, but they were processed independently. The FPU is a large piece of combinatorial mess (larger than the IU), with double precision data paths, it is too “expensive” not to be fully exploited. It needed a big overhaul.
Now, many instructions have ‘one cycle throughput’: as long as operands are independent, the FPU can begin a new instruction every cycle. Exceptions are double precision multiply, divisions and square roots and operations with denormal numbers.
The new architecture also features a few optimizations, like faster forwarding of results between dependent instructions.
Last but not least, instructions now take one less cycle to complete: A FADD now lasts 4 cycles instead of 5.
In addition to the existing Xilinx SystemACE CompactFLASH interface, it is now possible to use a SD/SDHC/MicroSD/MMCplus/MMCmobile card as the [SCSI] hard disk, using a small daugterboard with a SD connector and a few resistors plugged into the SP605 board.
This new interface is potentially faster (with quality SD/MMC cards) and not being based on obsolete proprietary chips like SystemACE, it could help porting the design to other boards…
The hardware debugger can control CPU operations from a serial port. It can run and stop the CPU, pick some registers and make it execute any instruction; it also manages one data and one instruction breakpoint.
As there is only one serial port on the SP605 board, it must be used both for the console and for the debugger, toggling is done using either the CTS signal or special “break” characters.
In the archive there is also a C program which is both a terminal communicating over the serial port and a debug monitor able to control the hardware debugger. Using this program, you can read and write registers, read and write virtual and physical memory, disassemble code, manage breakpoints, etc.
This debugger program is not complete, but it is already quite useful.
The most important missing feature is probably a GDB interface.
There are also some blocks which were moved to simplify retargetting the design to other boards, and a few tweaks for compatibility with Alteras (Quartus can compile the not-Xilinx-specific-parts of R4)…
All these subjects will be detailed in future articles. The FPU deserves many.
This development cycle was quite difficult; the release comes much later than expected.
And there will be certainly a R4.1 soon!
Just curious but does the SD interface take any inspiration from the SCSI2SD or was it developed entirely independently?
Also is the hardware debugger basically the same as the monitor in a sun prom or is it something different?
Sounds like I’ll have to have a go at building it in Quartus and see how much space it takes up on my board minus memory interface etc…
Also your little human test thing below sometimes asks me to type things that make no sense and it doesn’t work if I just copy it from what I remember. This time I got convert x to binary.
-The SD interface is mainly derived from the previous ‘CompactFLASH + Xilinx SystemACE’ disk emulation (scsi_sysace.vhd, scsi_sd.vhd). It is a microcoded design, I’ll post the microcode source.
SD/MMC card initialisation is done with a lot of bit-banging in OpenBIOS : Quite ugly.
-I have never used Sun prom’s debugger. This is a remote debugger meant to be used on a host computer. The internals are quite sound but the interface is very primitive. You can see the list of supported commands in “command.c”. Ideally, a GDB remote agent should be added to the debugger, allowing to control directly the CPU through GDB, and the GUIs using GDB.
-I have installed Quartus and started to port the design to your Terasic board. I have made a plomb_avalon bridge, a bridge for the “EPCQ256” FLASH which could ultimately be used for storing OpenBIOS, connected the µSD interface… There are still a few things to glue togeter, but I hope I will be able to send you a first version this week…
(I’ll check the test thing. Just a random WordPress plugin…)
Oh cool thats quick, I tried setting up a project in quartus but for some reason it lost my top level design … I’m often to tired at night to ponder such things heh. The hour drive from work doesn’t help.
Perhaps I should focus more on the hardware side and design a cheap ethernet adapter.. since thats more my strong point lately. Possibly based on http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en542414&redirects=ENC424J600 which is controlled though SPI or parallel interfaces? The wiznet controllers are nice for MCU based stuff but probably too high level since they implemnt TCP/IP in hardware. Any idea if openbios can netboot like a real sun? Also is there anything else you particularly find missing from these boards?
I think the mating connector for the HSMC port may be this. http://www.digikey.com/product-detail/en/QTH-090-02-L-D-A/SAM8194-ND/1106538
Don’t worry too much about the wordpress thing… I usually just copy my comment and refresh th page and I get one that makes sense.
From my POV, I would describe Quartus and particularly Altera’s IPs customisation and use, the Avalon bus, and this awful thing named ‘Qsys’ as “hostile”.
It won’t work on first try, and you will also have to tune a few details (for example the initialisation sequence for the HDMI transmitter). This is far from done !
For Ethernet I don’t know. Any MII or RMII Ethernet PHY (with transformer, connector) would be enough. Maybe a SFP module could be used, but they are usually very expensive (There is a SFP cage on the Xilinx board, but I don’t have any SFP module yet).
OpenBIOS could netboot if someone takes the time to implement it : a TFTP client, a driver for the Ethernet controller… Maybe it could be taken from other projects like UBOOT. (The “LANCE” Ethernet controller was started before SCSI disk emulation because at first I through that it could be used diskless, before realizing that OpenBIOS did not support netbooting!)
Hmm SPI ethernet would be easier I think. But possibly harder to implment LANCE on top of.. and it would be slower. RMII doesn’t look terribly complex though at least. I also came across http://opencores.org/websvn,filedetails?repname=smii&path=%2Fsmii%2Ftrunk%2Fdoc%2FSMII.pdf which details SMII …. which might be of interest since it uses fewer pins it runs at 125Mhz though.
Were you able to acutally get a Cyclone V GX board?
Maybe things like that could be connected to the 40 pins GPIO connector : http://www.wvshare.com/product/LAN8720-ETH-Board.htm, http://www.wvshare.com/product/DP83848-Ethernet-Board.htm. Also available on eBay. RMII is a bit simpler than MII because there is only one clock both for TX and RX. And fewer signals. The MII Ethernet MAC is in “ts_lance_mac.vhd”. The LANCE core, with registers and DMA engine, should not need to be modified. For RMII, data is transmitted over 2 bits instead of 4 bits, but it is essentially the same thing, so modifying the MAC or using a MII<->RMII converter should be easy.
I don’t have any Cyclone board yet. I will wait for your feedback !
I first succeeded to compile the whole thing on Quartus yesterday, there are timing errors and probably lots of other issues, but it is a first step. It indicates ‘logic utilisation = 38%’.
(Should I create a forum? The Web-hosting management panel proposes automatic installation of “PHPbb, SMF, myBB, PunBB, Beehive, bbPress” and many others… Any advice ?)
38% sounds very encouraging … perhaps room to fit 2+ cpus or deeper/more complex pipelines.
I hadn’t considered the GPIO header.. it does indeed look like that would be easier than the HSMC connector. There are 40 GPIO pins shared with the arduino header and 2 of the digit displays… So adding an ethernet board seems like a solved problem almost it would still be nice to have an adapter board to connect the RMII Ethernet board to though…. and some other things more SD cards maybe? Or a USB controller?
It looks like there is a ULPI wrapper here so open source UTMI USB function cores can be used http://vr5.narod.ru/fpga/usb/index.html …. it does seem to default to device mode rather than host mode though.
I haven’t looked at the code too in depth but there VHDL code for what appars to be 4-bit mode SD interface which should be vastly faster than SPI 1-bit mode. I think EMMC 8bit mode might be just another further extension of the SD card modes.
BSD licensed VHDL for 4bit sdcard: