<janrinze>
ZipCPU: i noticed that the ZipCPU should be able to run at 40MHz on the IcoBoard. The timings for my own cpu design show that 16x16 multiply is around 40 ns. how did you manage 32 bit at 40 MHz?
<ravenexp>
not all cpus do mul in a single cycle
<ravenexp>
well, most don't
eduardo__ has joined #yosys
cemerick_ has joined #yosys
eduardo_ has quit [Ping timeout: 240 seconds]
sklv has quit [Remote host closed the connection]
<ZipCPU>
The ZipCPU will do a multiply in 1-4 cycles, depending on how you set up the code. 7-series can usually do 3 cycles IIRC, Spartan 6's require 4.
<ZipCPU>
The iCE40 design can't handle either, so the multiply instruction is an illegal instruction on that design.
<ZipCPU>
I'm hoping to trap it and replace it with a soft multiply ... I just haven't gotten that far.
<ravenexp>
ZipCPU: are you using DSP macros in xilinx?
<ZipCPU>
On the iCE40 the OPT_MULTIPLY option is set to zero, bypassing the multiply code
<ravenexp>
is xst able to make sense of this?
<ravenexp>
like infer 18x18 multipliers the dsp blocks have?
<ZipCPU>
xst uses the last one, and yes it can make sense of it
<ravenexp>
if I were making a soft CPU, I'd implement 18x18 muls in the hard blocks, and trap on anything larger
<ravenexp>
because I hate programmers
<ravenexp>
no hw division for them, either
<janrinze>
ZipCPU: Thanks for the clarification.
sklv has joined #yosys
<ZipCPU>
Oh, and as for the 40MHz ... the CPU will need to run at 50MHz on the icoBoard I'm running it on, and it can actually make that number.
<ZipCPU>
40 is a leftover from trying to find a bug, and it won't work with the SRAM on the icoBoard--something I haven't added to the design yet.
<ravenexp>
I wonder how many prorammers even know that bits [63:32] of the result exist
<janrinze>
ZipCPU: i can only manage around 33 MHz with my own CPU design..
<janrinze>
ZipCPU: is that number with using a cache?
<ZipCPU>
ravenexp: GCC knows.
<ZipCPU>
Couldn't fit the cache on the icoBoard
<ZipCPU>
Although ... the cache is one of my faster components--will run at 200MHz on a series 7, even though the ALU slows me down to 100 or so
<janrinze>
Okay, so no cache.. I have the memory shared between vga and cpu so that limits the bandwidth a bit to SRAM.
<ravenexp>
there's been exactly 0 times I saw our programmers doing anything other than 32x32->32 muls or even bothering to check for overflow
<ZipCPU>
Library code requires 64-bit support.
<ravenexp>
that could be handled with software emulation like divisions
ravenexp has quit [Quit: WeeChat 2.1]
ravenexp has joined #yosys
<ZipCPU>
I suppose
GuzTech has joined #yosys
promach_ has joined #yosys
jkiv has joined #yosys
jkiv has quit [Max SendQ exceeded]
jkiv has joined #yosys
jkiv has quit [Max SendQ exceeded]
jkiv has joined #yosys
dmin7 has quit [Ping timeout: 264 seconds]
jkiv has quit [Ping timeout: 268 seconds]
proteusguy has quit [Ping timeout: 248 seconds]
proteusguy has joined #yosys
emeb has joined #yosys
promach_ has quit [Ping timeout: 268 seconds]
<janrinze>
ZipCPU: How did you get a compiler for your CPU?
<ZipCPU>
I used GCC, and built the backend myself.
<janrinze>
ZipCPU: I resorted to writing my own compiler.. hope that the target system will be able to compile code for itself..
<janrinze>
ZipCPU: using gcc implicitly imposes a lot of things to be supported by the cpu, right?
<ZipCPU>
Such as ...?
<janrinze>
okay.. perhaps i was mistaken there.
<janrinze>
i've only built a 16 bit cpu which does not have many instructions.
<ZipCPU>
GCC supports other 16-bit architectures.
<janrinze>
16 bit pointers..
<ZipCPU>
I'll also point out, I needed to change the ISA to get linking to work ... ;)
<janrinze>
so max 64KB range.
<ZipCPU>
Sure!
<ZipCPU>
The ZipCPU originally supported only 32-bit bytes. Getting that to work with GCC was my first success.
<ZipCPU>
It now supports 8-bit bytes, so GCC support is a bit simpler.
<janrinze>
16 bit bytes here :-)
<qu1j0t3>
ZipCPU: did you do a writeup on the gcc backend?
<ZipCPU>
No, not yet. I've wanted to. It's on my to do list. I'm just not quite certain how to dip into it without going into it whole hog--if you know what I mean.
<awygle>
happy easter, ZipCPU
<qu1j0t3>
yeah, i'm sure it's a big project. a lot of people would benefit though
<ZipCPU>
The other problem is ... I'm not sure to what extent an FPGA programmer would want to dive into GCC internals. CPU designers, definitely, general FPGA designers? I'm not certain.
<qu1j0t3>
people doing backends for historical cpus are definitely out there
<janrinze>
yup. understand that.
<awygle>
janrinze: the msp430 backend is actively supported and that's a 16-bit architecture (except when it's 20-bit but never mind)
<ZipCPU>
Also ... I think I want to merge the ZipCPU into GCC mainline. That means I need to go into binutils mainline first, and in particular I'll need to clean up my assembler backend ... lots of work.
<janrinze>
hence i resorted to writing my own compiler. I was able to write that in 2 weeks. I doubt i could finish reading up on gcc internals in two weeks..
<ZipCPU>
It took me about 2-3 months to build a GCC backend.
<qu1j0t3>
ZipCPU: that would be really nice, but will they merge it? They have been known to yank real, important cpus
<ZipCPU>
Then another 2-months to rewrite it for 8-bit bytes ...
<ZipCPU>
qu1j0t3: Good question. Not sure I really know the answer. It'd be nice to know.
<ZipCPU>
I guess all I can do is ask when I get to that point.
<janrinze>
ZipCPU: with gcc it means that C++ can be used too?
<ZipCPU>
Basically, although I don't really have a good and thorough test suite to know.
dys has quit [Ping timeout: 260 seconds]
<ZipCPU>
I mean ... the back end I've built should theoretically support every front end. However, I haven't tested them all, and each front end uses the back end differently so ...
<ZipCPU>
Let me try things this way ... you are invited to experiment with the ZipCPU's back end and your favorite language. If it doesn't work, let me know and we can look at it together. :D
<janrinze>
If i can find time to look at the ZipCPU then I will let you know. For now I am indulging myself in this whole computer-from-scratch experience. ;-)
<ZipCPU>
janrinze: Enjoy! You might argue that the ZipCPU was just exactly that from my perspective. There's a *lot* of road, though, between the drawing board and playing 4x4x4 tic-tac-toe using the C-library.
<janrinze>
yes. I am now doing some graphics demos as test bench
<ZipCPU>
Did you find my VGA simulator at all?
<ZipCPU>
It's more of a display simulator than a VGA simulator ... but I named it a VGA simulator, and the name has held.
<janrinze>
I started with an Acorn Atom in-a-fpga some two years ago.
<awygle>
Ada-on-ZipCPU
<janrinze>
so i could easily swap the 6502 cpu there with a new cpu.
<ZipCPU>
:D
cr1901 has quit [Ping timeout: 256 seconds]
<ZipCPU>
awygle: Are you just trying to get me started? :P
<ZipCPU>
janrinze: There was a wonderful O/S text on OpenCores. When I wrote to the author to tell him how much I loved reading through it, he said that though he had built his own ISA for his CPU at first, he stopped doing it.
<ZipCPU>
There was just too much work involved in maintaining the port of the tools
<janrinze>
oh, but of course.
<awygle>
ZipCPU: get you started learning ada so you can help get ghdl support into yosys? maybe.
<ZipCPU>
awygle: Would you believe that I originally wrote the F-16 flight sim for my masters degree thesis in Ada?
<janrinze>
technically a 64K-word system won't run much stuff you can grab in c-sources.
<ZipCPU>
janrinze: There was also a fascinating comment in the GCC soft FPU emulation code: "Here's a quarter kid, go get yourself a real CPU"
<ZipCPU>
This was the error message if you tried to compile the FPU emulation on a machine that didn't support 4-byte integers.
<janrinze>
true that.. even a cortex M-0 does not have FPU..
<janrinze>
back in '97 we could hardly get gcc to produce code for the ARM without doing some inline assembly to fixup things..
<janrinze>
the ARM sprouted from the legacy Acorn Atom and it's siblings. so to me this is sort of a walk through alternative time line. ;-)
<janrinze>
ZipCPU: have you tried the ulp5K yet?
pie___ has joined #yosys
digshadow has quit [Ping timeout: 268 seconds]
pie__ has quit [Ping timeout: 264 seconds]
cr1901_modern has joined #yosys
AlexDaniel has joined #yosys
digshadow has joined #yosys
<ZipCPU>
janrinze: Nope, not yet
leviathan has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
emeb_mac has joined #yosys
emeb_mac has quit [Client Quit]
GuzTech has quit [Ping timeout: 276 seconds]
danieljabailey has quit [Quit: ZNC 1.6.5+deb2build2 - http://znc.in]