Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Ads
Discussion Groups
Discussion Groups | FPGA-CPU | it breathes - milestone
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
it breathes - milestone - Rob Finch - Sep 29 8:15:00 2005
Dual cpu system...
Got it working I think.
One cpu is constantly updating some characters on the screen, while
the other is running downloads and stuff. The "fun" part was getting
the shared memory controller to work properly. It uses a combination
of priority and random selection for arbitration. Dual port rams are
being used so that both cpu's can execute code at the same time. It's
very tempting to make a quad/octa cpu version. (I can see it now...
an
eight cpu version running at effectively 320 MHz total....- each cpu
running at 40MHz)
The cores have a cpu number in a special register of the cpu, so the
cpus can run different code based on it's number.
Rob
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Got it working I think.
One cpu is constantly updating some characters on the screen, while
the other is running downloads and stuff. The "fun" part was getting
the shared memory controller to work properly. It uses a combination
of priority and random selection for arbitration. Dual port rams are
being used so that both cpu's can execute code at the same time. It's
very tempting to make a quad/octa cpu version. (I can see it now...
an
eight cpu version running at effectively 320 MHz total....- each cpu
running at 40MHz)
The cores have a cpu number in a special register of the cpu, so the
cpus can run different code based on it's number.
Rob
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: it breathes - milestone - Eric Smith - Sep 29 14:04:00 2005
Rob wrote:
> The "fun" part was getting
> the shared memory controller to work properly. It uses a combination
> of priority and random selection for arbitration. Dual port rams are
> being used
If you're using dual port RAMs, you shouldn't need any arbitration
except for atomic read/modify/write cycles. Those should normally
be infrequent enough that either simple priority or rotating priority
(which for two CPUs is just alternating) should work fine.
> an
> eight cpu version running at effectively 320 MHz total....- each cpu
> running at 40MHz)
For 40 MHz CPU cores, you should be able to time-multiplex the use of
BRAMs and still avoid most need for arbitration.
Eric
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
> The "fun" part was getting
> the shared memory controller to work properly. It uses a combination
> of priority and random selection for arbitration. Dual port rams are
> being used
If you're using dual port RAMs, you shouldn't need any arbitration
except for atomic read/modify/write cycles. Those should normally
be infrequent enough that either simple priority or rotating priority
(which for two CPUs is just alternating) should work fine.
> an
> eight cpu version running at effectively 320 MHz total....- each cpu
> running at 40MHz)
For 40 MHz CPU cores, you should be able to time-multiplex the use of
BRAMs and still avoid most need for arbitration.
Eric
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: it breathes - milestone - Rob Finch - Sep 30 0:08:00 2005
> If you're using dual port RAMs, you shouldn't need any arbitration
> except for atomic read/modify/write cycles. Those should normally
> be infrequent enough that either simple priority or rotating priority
> (which for two CPUs is just alternating) should work fine.
>
Ooops! Maybe more detail. The Spartan3 Starter Board is being used.
For main memory the system uses the SRAM which has to be shared
through via an arbitrator since it's only single port. There's ROM
code in block ram, that part doesn't use an arbitrator. Cpu #0 has all
the IO connected to it through a local bus that doesn't go through
arbitration. There's actually a video controller, hardware cursor
controller, and audio controller also with access to the SRAM. So there
s more channels. I have the video and audio going through a simple
priority arbitration.
> > eight cpu version running at effectively 320 MHz total....- each
cpu
> > running at 40MHz)
>
> For 40 MHz CPU cores, you should be able to time-multiplex the use of
> BRAMs and still avoid most need for arbitration.
I'm planning on using an separate instruction cache for each
processor. But that has to wait till the system works a bit better.
It's "purple" screening me right now. It clears the screen to a purple
color but it's supposed to be pale yellow. I guess it has a mind of
it's own.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
> except for atomic read/modify/write cycles. Those should normally
> be infrequent enough that either simple priority or rotating priority
> (which for two CPUs is just alternating) should work fine.
>
Ooops! Maybe more detail. The Spartan3 Starter Board is being used.
For main memory the system uses the SRAM which has to be shared
through via an arbitrator since it's only single port. There's ROM
code in block ram, that part doesn't use an arbitrator. Cpu #0 has all
the IO connected to it through a local bus that doesn't go through
arbitration. There's actually a video controller, hardware cursor
controller, and audio controller also with access to the SRAM. So there
s more channels. I have the video and audio going through a simple
priority arbitration.
> > eight cpu version running at effectively 320 MHz total....- each
cpu
> > running at 40MHz)
>
> For 40 MHz CPU cores, you should be able to time-multiplex the use of
> BRAMs and still avoid most need for arbitration.
I'm planning on using an separate instruction cache for each
processor. But that has to wait till the system works a bit better.
It's "purple" screening me right now. It clears the screen to a purple
color but it's supposed to be pale yellow. I guess it has a mind of
it's own.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )