Hi everybody
I am trying to  familiar to xps software .So i am trying to create a
peripheral using 2kb bram block in which we can read or write. I have
written verilog code for a bram controller atteched to  opb bus.Now i
have to write a c code which perform read and write operation in that
bram block.Regarding this i have following confusion in my mind
1-For write operation following signal should be given in sequence
 a- m1request
 b-opb select
 c-opb address bus
 d-opb data bus ...  etc

opb bus has different frequency as that of microblaze processor ..how
is it possible to put these signal on bus in sequence  by a c
programe.C
Can anyone suggest some solution or give a model code for our
reference ?


thanks in advance

rajiv

On Jun 14, 5:55 am, rajiv...@gmail.com wrote:

> 1-For write operation following signal should be given in sequence
>  a- m1request
>  b-opb select
>  c-opb address bus
>  d-opb data bus ...  etc
>
> opb bus has different frequency as that of microblaze processor ..how
> is it possible to put these signal on bus in sequence  by a c
> programe.C

Well, usually, you hook things up so that your processor handles all
of that for you.

Your peripheral would either be memory mapped, in which case you just
need to learn about using the "volatile" tag and absolute hardware
address to convince your C compiler to really access the memory.

Or else your peripheral is io mapped, in which case you have to use
the approrpiate process to access io space.

Rarely, someone will map the control signals for a device into
registers that are in turn memory mapped or io mapped, and it will be
up to software (perhaps a kernel mode driver) to toggle the bits to
accomplish the necessary sequence of operations.  In that case, you'd
just do a bunch of memory or io accesses to accomplish the script you
gave.

-------

No meaning to personally target you here, but can I ask a general
question: what is up with the recent flood of people apparently having
no background embedded programming experience playing with soft core
FPGA processors?

Generally, you want to have some experiencing programming embedded
processors before you try to make your own customized embedded
processor...

c...@hotmail.com wrote:

> No meaning to personally target you here, but can I ask a general
> question: what is up with the recent flood of people apparently having
> no background embedded programming experience playing with soft core
> FPGA processors?

Because it's so cheap and easy?

Phase 1. $600 for EDK + a decent Spartan3 board, plus free webpack tools
Phase 2. ????
Phase 3. Profit!

On Jun 14, 8:37 pm, John Williams
<jwilli...@itee.uq.edu.au> wrote:
> cs_post...@hotmail.com wrote:
> > No meaning to personally target you here, but can I ask a general
> > question: what is up with the recent flood of people apparently having
> > no background embedded programming experience playing with soft core
> > FPGA processors?
>
> Because it's so cheap and easy?
>
> Phase 1. $600 for EDK + a decent Spartan3 board, plus free webpack tools
> Phase 2. ????
> Phase 3. Profit!

That ain't cheap.  Cheap is doing it with the $100 s3kit, coding up a
processor described in MIT open courseware web notes, simulating it in
iverilog, hacking the gcc-cross target until it builds under cygwin
*and* produces working code... rewriting an assembler...

> That ain't cheap.  Cheap is doing it with the $100 s3kit, coding up a
> processor described in MIT open courseware web notes, simulating it in
> iverilog, hacking the gcc-cross target until it builds under cygwin
> *and* produces working code... rewriting an assembler...

That is exactly what i keep saying around the net!

Cheap is writing down the MIT Beta (that's the one you refer to if i'm
right), simulating it in iverilog (or GHDL since i use VHDL only) and
working on the toolchain.

Still we don't have an open-source implementation tool (or at least
for the synthesis part). "Signs" is progressing but i don't think it
supports any real architectures.

Most soft cores out there are wildly unoptimized. This is where Xilinx
did a good job with both MicroBlaze and Picoblaze.
And of course i would prefer a soft core written in general VHDL (i.e.
not for a specific vendor). I think the compromise would be rather
small, given that internal RAM storage and multiplier(s) will be
inferred from the general HDL code.

Nikolaos Kavvadias

On Jun 15, 3:15 am, Uncle Noah
<n...@skiathos.physics.auth.gr> wrote:
> Cheap is writing down the MIT Beta (that's the one you refer to if i'm
> right), simulating it in iverilog (or GHDL since i use VHDL only) and
> working on the toolchain.

Yes, that's it.

> Most soft cores out there are wildly unoptimized. This is where Xilinx
> did a good job with both MicroBlaze and Picoblaze.

Yeah, Beta's 32x32bit register file ended up as lutram... not exactly
efficient.  The old two read ports and one write port problem...
Also, the 32 bit instruction words are fairly wasteful of BRAM code
space.  And if you aren't going to pipeline, a RISC design isn't
necessarily such a great idea.  But still, it worked, and it ran in an
XC3S200...

There are some more FPGA-appropriate open architectures out there I
think, even some open source microblaze workalikes.