[Oberon] Wojtek's comment
Jan de Kruyf
jan.de.kruyf at gmail.com
Fri Aug 28 16:47:57 CEST 2015
Hallo Peter,
Don't know whether you followed the thread about Wojtek's needs in FPGA
programming.
This whole write up was mainly addressed to that need, and obviously to
generate discussion. So thank you for replying.
I am very aware of Native Oberon's way of doing things. If you look long
and hard you will still find my name in some beta-testers list from the
time that Peter Muller ran Native + Gadgets.
> a static one for the inner core
This seems one of the trade secrets of ETH :) never found any code yet. I
am aware it exists.
> Not the only one...
To be studied. I am always enthusiastic that I will deliver, from happy
experience lets say.
> I don't see how this could work.
Perhaps calling it the linker script leads people astray.
In an earlier post I wrote this:
-- So this morning I had a quick look in chapter 14 of the new 'Project
Oberon' and in the source files
-- that control the boot process. At the moment most addresses are hard
wired and difficult to decipher for a novice.
-- So I think what might be done is: make a 'boot parameter' module, that
exports just the required variables
-- with copious explanation --, that is imported into the regular
bootloader, Kernel etc.
This was in response to the need to execute code from high speed Bram and
the need to memory map hardware on his FPGA.
> As soon as you have RECORDS or ARRAYS
I am aware of that limitation.
> This has to be proved.
Obviously.
> I don't see any benefit at all.
Ultimately not for me to decide at this moment. I would have to see the
exact requirements and do a comparative study of the problem, and do some
timing comparisons _in this specific problem space_ before deciding.
I do think that Wojtek is pushing the limits here, but then if the limits
do not get pushed there will be no invention an we all slowly doze off.
So to some up my response to your most valued critique:
1. Yes it is a bad idea to modify the Oberon runtime, but I feel it might
be possible.
2. I agree with Wojtek that in order to successfully program FPGA's some
unorthodox ideas are needed.
Note in this respect the length of time the group needed to come up
with an acceptable replacement
for the original FPGA. Not very encouraging.
2. For a one off design, to modify the runtime is infinitely more
preferable than modifying the compiler or even linking a static image that
then has to be moved part wise on startup.
3. Some more study is needed of the problem, before we commit ourselves
this way or that way.
Cheers,
j.
On Fri, Aug 28, 2015 at 3:48 PM, Peter Matthias <PeterMatthias at web.de>
wrote:
>
>
> Am 28.08.2015 um 13:29 schrieb Jan de Kruyf:
> > Hallo,
> > I like to get some comment here from the people in the know!
> >
> > On the matter of memory mapping things in any Oberon.
> >
> > As an introduction:
> > 1. Oberon has not got a linker (except in some cases Chris mentioned).
> > Linking is done dynamically as and when the system decides a module is
> > needed.
>
> Oberon not only has one linker, it has two linker. a static one for the
> inner core and a dynamic one for the rest.
>
> > 2. In Oberon there is no clear boundary between "runtime library",
> > "operating system" and "user-land" like we have in linux or any other
> > os. On the contrary the boundary is very fluid. What I called the
> > runtime just now, might just as well be called a more permanent part of
> > user-land (in the sense that is is almost always loaded) The only real
> > distinction is "boot-loader" and "applications"
>
> Yes, no clear boundary between Kernel, OS, Libraries and Application.
>
> > 3. Where in the past the compiler was attacked, it was to prove a
> > radically new concept: Oberon-V4, Xoberon, Component Pascal and Active
> > Oberon come to mind. In the greater scheme of things Oberon 7 is merely
> > a revision of Oberon 2.
> > So in other words: the number of language dialects have been kept to a
> > minimum, although there are perhaps too many already.
>
> At least too many per user ;-)
>
> > Although I might partly agree that to be able to assign an address
> > attribute to a variable sounds like a nifty idea, I am not in favour of
> > it. Because then we should rather look more generally into the matter of
> > assigning attributes to things. And that will open up a huge can of
> > worms. In fact such a huge can, that I advise to use Ada instead, where
> > you have such a need.
> > Secondly my experience is that it needs solid planning and strict
> > discipline to keep all the address attributes together in one place, so
> > the whole circus stays readable and maintainable.
> >
> > This leaves us with the boot-loader / application space to reach our
> > goal, since using a linker is a bit 'uncool', to be prevented where we
> > do not need it.
> > That is why I proposed earlier to use a system-constants Module. It is
> > neither here nor there if we create such a thing or not. The language
> > stays the same and is readable and the program stays maintainable by
> > anybody conversant with the art. It is just another part of "application
> > space". And the idea is widely portable.
>
> System parts in application space seems a bad idea to me.
>
> > In the same vein I like to propose that we have a careful look at the
> > way modules get loaded.
> >
> > Say we have a Module with only exportable variables that occupy a
> > contiguous range in memory (like for memory mapped io), in fact for a
> > different range of memory we might simply create another Module.
> > So we create pairs:
> > Range of memory -- Module,
> > Range of memory -- Module,
> > etc.
> > Now the only difficulty left is to actually get them loaded with their
> > variables overlapping the range of memory we had in mind when we created
> > the Module.
>
> Not the only one...
>
> > At this moment in time, having had a very brief look at the system
> > software, I believe this is not too difficult to arrange.
> > Perhaps the system-constants Module might contain the table of pairs
> > mentioned above, or we might find another acceptable way.
> >
> > This idea might in fact also take care of hardware system flags under
> > software control, like a cpu speed flag.
> > All you need to do is import the relevant module, and there you have
> > your hardware-locked-in-place variables ready to be manipulated.
> >
> > Advantages over most other schemes I know of:
> >
> > 1. We still don't need a linker. In fact the linker script, that great
> > source of unknown darkness, is replaced by the system-constants Module;
> > and then only partly.
>
> I don't see how this could work.
>
> > 2. All address attributes to variables are of necessity kept in one
> > place. Any hardware locked variable is easily recognized in the program,
> > since it is imported from one of these special modules.
>
> For variables of basic types this might work.
>
> > 3. a set of programs without hardware locked variables will still
> > function as it always has, even if a system is modified to accept
> > hardware-locked-variable modules. It is completely transparent.
> >
> > 4. The compiler is left alone, no need to break things that work!
>
> As soon as you have RECORDS or ARRAYS the compiler has to be involved.
> The addresses would have to be some kind of pointers. Records have a tag
> the compiler has to be aware of. Array have size information as first
> data...
>
> > 5. the idea is easily ported to any embedded processor.
>
> This has to be proved.
>
> > 6. it is elegant and minimalistic, with maximum benefit.
>
> I don't see any benefit at all. Hardware programming is inherently
> unsafe. Adding type safety to its registers just adds nothing. Native
> Oberon shows that hardware driver easily can be well abstracted and
> written in a module.
>
> Regards,
> Peter
>
> >
> > Enjoy,
> >
> > j.
> >
> >
> >
> > On Thu, Aug 27, 2015 at 4:52 PM, <skulski at pas.rochester.edu
> > <mailto:skulski at pas.rochester.edu>> wrote:
> >
> > Juerg:
> > > 1) sometimes it is necessary to put data in fast memory
> > > (I think you mean BRAM)
> > > 2) you would like to process your ADC data (stored in BRAM)
> > > in Oberon.
> >
> > Let me make it clear for those in the audience who are new to the
> FPGA
> > design. BRAM is a dual port memory. It has many uses which I can
> discuss
> > if there is interest. Here we are talking of data acquisition (DAQ)
> > with a
> > few nanoseconds per data sample. A typical high performance DAQ
> design
> > uses BRAM port A to write data from the converter, and it uses port
> B to
> > access the data when the DAQ stops. (Think of a digital
> > oscilloscope.) The
> > data needs to be accessed in situ. Copying it to slow memory would
> > render
> > the instrument slow and unusable.
> >
> > The bottom line: there is need to map a BRAM to the processor's
> memory
> > space. This has been discussed by Jan (thank you, Jan!). His
> > prescription
> > is low level. OK, let be it. But let me make it clear that moving
> > the data
> > is not permitted. Accessing the data without moving is necessary.
> >
> > Furthermore, the code which implements the data processing needs to
> be
> > executed from BRAM as well. (It will be a different block of BRAM.) I
> > think that RISC5 can run at some 100+ MHz when it executes from
> BRAM. We
> > have looked at the RISC5 Verilog and we see that it needs to be
> reworked
> > in this direction. Hopefully it can reach 100+ MHz from BRAM. Then
> the
> > slow code can be put into off-chip SRAM and we can use the stall
> > signal to
> > slow the processor down to match the SRAM.
> >
> > >From this discussion it follows that we need to map both the
> > variables and
> > the code to particular addresses. The mechanism for doing this needs
> > to be
> > specified somehow. Of course we can take the Oberon System and hack
> it,
> > but this would be ugly. I am hoping that a sort of agreed-upon
> approach
> > will emerge from this discussion.
> >
> >
> > > Oberon works with what you call slow memory. So if you want to
> process
> > your fast data with the slow Oberon, why not put the data in the slow
> > memory in the first place?
> >
> > Performance will be unacceptable. In our design we will use
> "ping-pong
> > buffers" implemented in BRAM. When one BRAM buffer acquires the
> > data, the
> > previous data from the other buffer is being processed in situ.
> >
> > > - Jan proposes a copy approach BRAM to SRAM
> >
> > Unacceptable for the performance reasons.
> >
> > > and then process by Oberon - Chris proposes a mapped memory
> aaproach.
> >
> > This is the way.
> >
> >
> > > To understand the Oberon memory layout have a look at figure 8.1 in
> > chapter 8 of project oberon.
> > > You see basically that the Oberon system splits memory in four
> blocks A
> > memory for module code
> > > B memory for procedure variables (called stack)
> > > C memory for dynamic variables allocated with NEW (called heap)
> > > D memory for IO (display frame buffer and IO registers)
> >
> > We need to statically allocate variables to HW addresses. Would be
> > really
> > nice to have this facility for both the scalar variables (aka
> > "registers")
> > and arrays which will be overlaid over BRAM blocks.
> >
> > Furthermore, we need the facility to specify that certain code is
> > executed
> > from BRAM to gain performance. This can be specified per module to
> keep
> > with the modular spirit of the language. A finer granularity would be
> > complicated and not necessary.
> >
> > Here we are talking of a factor 5x in performance between BRAM and
> > external SRAM. This is not a small optimization. It is quite crucial.
> >
> > At present there is the single MODULE* which is locked into BRAM, so
> we
> > are almost there. I hope that we can use the MODULE* as the "system
> > library" of sorts, where the performance-critical code will be put
> and
> > called by the "slow code" that lives in SRAM. However, it is a hack.
> It
> > would be really nice if the memory allocation could be specified for
> > regular modules as well, on a per-module basis.
> >
> >
> > > This layout is flexibly established during booting by two
> constants in
> > the
> > > boot record, called "heapOrg" and "heapLimit".
> > > A starts at 0 and grows upwards
> > > B starts at heapOrg and grows downwards
> > > C starts at heapOrg and grows upward til heapLimit
> > > D starts at heapOrg+heapLimit
> > > Now, I think you don't like Jan's copy approach. So you could do
> the
> > following memory map approach: Reduce "heapLimit" and map the memory
> > range
> > > just below the VGA framebuffer to your BRAM (this mapping has to
> be done
> > in Verilog)
> > > You can declare in Oberon a safe TYPE to your ADC data (e.g.
> POINTER TO
> > ARRAY 256 OF BYTE) and allocate the start address of your mapped BRAM
> > memory to a pointer variable.
> >
> > I think this is all good. It is a bit of a hack put on top the
> classic
> > design, but it looks workable to me. Thank you for the suggestions.
> >
> > Jan wrote:
> >
> > >> But we can do without a version for every toy about town
> >
> > I am discussing features that may seem exotic to a computer
> scientist.
> > These "toys" are not toys for an electrical engineer working with
> FPGAs.
> > They are in fact fundamental in the realm of FPGA design. My point
> > is that
> > the FPGA Oberon System is running in the FPGA. It would be good to
> know
> > how the FPGA Oberon can help using the FPGA to the fullest extent.
> If it
> > does then it will become a much more attractive tool.
> >
> > Thank you,
> > Wojtek
> >
> >
> > --
> > Oberon at lists.inf.ethz.ch <mailto:Oberon at lists.inf.ethz.ch> mailing
> > list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
> >
> >
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150828/ea691ca6/attachment-0001.html
More information about the Oberon
mailing list