Many thanks for the comments. As Max has stated, I know nothing about these strange and dark FPGA devices.
I've always assumed, incorrectly probably, that they were just some form of serial instruction processing device like any other PIC / ATMEL etc.
My problem is I'm still thinking in PIC technology and methods.
For example, the PIC I'm currently using runs at 64MHz, but needs 4 cycles per instruction, so instantly youíre down to 16MHz. To read memory for example, the 24-bit address has to be output by the PIC, but this isnít as straight forward as one would like. PIC ports are only 8 bits wide, so it takes at least 6 instructions to set up the address (read address word value, write it to the correct port). Then you have to set the MREQ signal to indicate your addressing memory and not I/O, and finally set the RD or WR signal. Next, transfer the data presented by the memory off the data bus into a holding register, then release the MREQ and RD signals.
As you can see, many instruction cycles have now elapsed and all Iíve managed to do is read a byte of memory and Iíve not done anything with it yet; itís all very slow.
Whilst I wasnít looking to break any land speed records with this machine, itís going to need to better than it is if itís going to be capable of running a custom multi-user operating system.
From whatís being said here, it looks like FPGAís will work better than a PIC in this application and are probably the way forward. The modular nature of the system means that itís quite simple to replace the CPU card with something different; that way I donít have to redesign all the rest of the hardware.
I think a good place to start would be an introduction to FPGAís.
Any suggestions ?
Iím pleased to know that you are a PicoBlaze fan Max and my apologies for not remembering you if we did met in the past. Iíll certainly consider your suggestion.
Back to the fictitious 8-bit micro and some concepts for Joe to consider when you have an FPGA at your disposal. My discussion will focus on the 24-bit program counter (PC) assuming a 16Gbyte memory with 24-bit address bus and 8-bit data. In an FPGA you could define any architecture in pure logic so the PC would be a 24-bit loadable counter and could run in excess of 100MHz in any device. ĎJUMP c, aaaaaaí would take at least 1-byte to define the operation and 3-bytes to define the absolute address. Hence the PC needs to increment 4 times to obtain the required in formation; 25MHz assuming the 16Gbyte memory fast enough to keep up with the PC at 100MHz.
May be we need to add more clock cycles (ĎT-statesí) to access a slower memory. May be decoding the jump instruction and testing the condition would be also be too slow to maintain 100MHz so we either run a slower clock or add T-states to break the task down into smaller faster stages.
Emulation is another way to use T-states. For a 24-bit PC you could connect 3x 8-bit ports to PicoBlaze (PB)that would determine what values to output to them. Every PB instruction takes 2 clock cycles so it takes 6 cycles to increment and 6 cycles to output. An 8MHz PC rate which is a bit sad! However, we are in an FPGA so can actually attach a 24-bit counter with byte loading capability so that PB only needs to output an increment control pulse and it can do that every 2 clock cycles taking us back up to 50MHz.
The exciting thing about an FPGA is that you can blend software and hardware. At first you tend to think of a processor and peripherals just like separate devices on a PCB but really itís the ability to blend the two schemes at a much finer granularity that makes it really interesting.
I designed a similar processor about 5 years ago. An 8-bit data path with 24-bit addressing for data and 14-bit addressing for (16-bit) instructions. The function was retrieval of mostly sequential data. It needed two cycles to fetch the instruction from the 8-bit memory and two to execute. Speed was not a consideration so I made no attempt to optimize for it. I suspect that an architecture tailored to your requirements would best suit your quest for speed.
Hi Ken -- I think we met a while back at some Xilinx event. I personally am a tremendous admirer of the PicoBlaze -- of course it wouldn;t work for what Joe is doing because of his 24-bit address space -- but you have to remember that Joe has never worked with FPGAs -- the trick is for us to get the word out -- how about your writing an article about the PicoBlaze for Programmable Logic Designline?
As the designer of PicoBlaze Iím a little sad that after 17 years of its existence that there is any need for a Ďfictitiousí discussion about an 8-bit processor in an FPGA. On a positive note, it tells me that there are still a lot more potential users of PicoBlaze out there and helps explain why there continues to be 20 to 30 new registrations for it every day after all these years.
Now as it happens Iím just about to release the next generation of PicoBlaze called KCPSM6 and Iíve been introducing its features on the PicoBlaze forum...
I have stated the performance. This does vary depending on your target FPGA device and speed grade.
-2 speed grade = 105MHz
-3 speed grade = 138MHz
-3 speed grade = 240MHz
All PicoBlaze instructions execute in 2 clock cycles under all circumstances providing very predictable performance and timing. So if you want to JUMP in 8.3ns then try PicoBlaze :-)
With the info given, it is not possible to give an accurate answer, but I recently saw a post comparing an Altera NIOSII/e running at 50MHz clock rate with an ARM. 200MHz designs are not uncommon, with the absolute max clock speed about 400MHz. My CEngine fmax is about 150MHz.
Let's see, 30us @ 64MHz .. 64 clocks = 1us .. so it is taking 1920 cycles to do a jump .. betcha an FPGA will beat the pants off that emulator by may be a couple of orders of magnitude.