[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] F-CPU SoC
Hi Yann,
On 04/02/2015 10:48 AM, whygee@xxxxxxxxx wrote:
Sorry. I think I used the term properly, it's just that I didn't
explained my thoughts. What I meant was that there's no one "true
F-CPU SoC". The SoC will use a profile-specific implementation of
the F-CPU ISA. And yes indeed, I'm talking about FPGA.
Speaking of profile : I've implemented a system to manage that with
the YASEP. It's very handy ! It must be more stable for F-CPU but the
"profiles" are not just an idea and few other CPU can boast this.
I was also thinking about using YASEP as a "helper" - it can provide
quite handy functionality, including remote debugging and host-assisted
I/O. It could be probably very handy for preparing the system memory
before the F-CPU boots (and thus removing the need for boot-rom), so
system developers can easily develop and test the bootloader.
If there are not much resources in the FPGA, the "helper" can be YASEP
on another board, or just any rpi/rpi2/riotboard/beaglebone.
I have some extra-pervert ideas for the tooling, but need some
more time before giving actual proposal :D.
please elaborate :-)
I'll do when I order my thoughts on the subject.
I can't wait !
I have several "starter kit" boards, one with the same AFS600
indeed, so I could prototype a few stuff, but also more powerful
boards with AFS1500, which might be ok for early F-CPU
implementations. However the I/Os are minimal, there is no
external RAM, the interfaces are lacking... so it can't implement
a whole system.
These FPGA are probably fine for the ISA development, but for
working on actual SoC the lack of memory interfaces (or enough I/Os
to do it the hard way), memory will be a limiting factor, imho.
The AFS1500 is a little beast so I bought several boards for
workshops to present the YASEP. But there is room for a reasonable
F-CPU (though the internal wire delays won't allow it to run fast)
There are enough I/O pins so an external memory board could be hacked
(I have a bunch of SRAMs).
Love the idea of SRAMs. But there's a practical limit of how much SRAM
you can put on the system by adding more chips. There are 2 big issues:
- adding address decoder for multiple SRAM banks will introduce delay
- having multiple SRAM banks means much higher capacitance on the data
lines, which will load to both FPGA and SRAM IO drivers. Probably the
FPGA is a tough beast and can source lots of milliamps to charge the
parasitic capacitance, but not sure about the SRAM IO drivers. This
needs to be verified.
The internal Flash is 1MB and can feed a RISC CPU's instruction
decoder at 100MHz
This could be nice for a boot-rom, but not sure that this is an actual
advantage for a general purpose CPU. Unless we make something like a
modern Amiga :D.
http://www.microsemi.com/products/fpga-soc/fpga/fusion#product-tables
There's enough SRAM for data cache.
So it's better than nothing for F-CPU development.
The chance is that the majority of people will use whatever
low-cost hobby board is available on the market, so there's zero
probability that these boards will be compatible with such common
interface.
For F-CPU, there is a need of a fast 64-bits wide data bus.
I totally agree. If we take for example 50MHz as the SoC bus clock, this
will allow 381 MiB/s peak bandwidth, which is definitely cool to start
with. Unfortunately wide buses are expensive (routing), and also address
decoders for wide buses are expensive (delay), so would be good to move
the low-speed IP cores behind a bus bridge, and leave only high-speed IP
cores on the wide bus.
Few hobbyist boards provide this.
In practice, all hobby FPGA boards will have somewhat different
power supplies, clocks, programming interfaces, pinouts/connectors.
So I would just leave it as is - let the guy who is porting the
F-CPU SoC to this specific board to take care of the board
specifics and to document which SoC signal goes where, and that
should work OK.
yup, however for our team's progress, we need a uniform platform
because otherwise we'd lose a lot of time dealing with each person's
board details...
I have slightly different opinion on this topic. The project is about
the freedom of choice, so let's not limit people. It's a matter of
arranging the work flow. You seem to be fine to take care of the
mainline version of F-CPU, which is being developed and tested against
what you have at hand (the Actel stuff). There could be another
developer, who's responsible for let's say Xilinx port of the SoC, and
his task will be to maintain the Xilinx port, like merging updates from
your mainline code, accepting/maintaing patches from other guys using
Xilinx boards, and proposing back generic patches to the mainline. If
you have experience with any major open-source project work-flow, this
would be the same.
So my proposal for F-GPU is to prototype it then build 8 or 12 of
them for the team's most active developers. The cost would be
bearable and the risk is low because the F-GPU is repurposable.
Yes.
If there's a need for interaction between several (possibly
different) FPGA boards, it would be easy to hack a homebrew cables,
as I don't see our designs soon to be clocked so high that we
couldn't make cables for them at home :D.
"assume nothing" ! :-D I got tricky issues even when I didn't expect
them...
Regards, Nikolay
YG
Regards,
Nikolay
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/