Contributing
by Stephen Rogers
Hi,
I was at Alex's talk earlier today at FOSDEM and I am very interested in
contributing to lowRISC in any way that I can. I have some experience
developing for LLVM and would really like to take a look at the work that
has been put into the lowRISC backend so far. I can't find any links to a
version control repository anywhere on the website. Is there anything
publicly available that I can look at now?
Cheers,
Stephen
8 years, 1 month
VM system support for tags and VA-indexed tag storage
by Dennis Ferguson
Hello,
I read the lowRISC memo with considerable interest. I think I like
the basic idea of tagged memory, but after thinking about the practical
implementation issues I decided the memo was mostly silent on what
seemed to me to be some of the more mysterious bits, that being what
the kernel VM subsystem needs to do to deal with memory tags.
I understand that the per-word tagging implementation is intended
to be logical, in that the plan is not to implement this by
widening the physical memory system but rather to store the tags
in separate locations using the physical address of each memory
word's location as an index to the word's tag bits held in separate
memory. For a bunch of reasons my best guess is that the VM subsystem
is likely to also want to deal with the tags as logical, not stored
with the pages of words the tags are associated with but rather
maintained in separate memory pages containing the tag bits for
multiple data pages, to keep track of the tags for pages not currently
in physical memory and to allow the tags themselves to be moved to and
from disk in page-sized chunks. This seems entirely analogous to the
planned hardware implementation of the tags, except while the hardware
implementation uses physical address indexing the VM system will be
dealing with a process's virtual address space with little concern for
(mutable) physical page addresses, and hence will want to keep the tags
indexed by virtual address instead. This seems to work, but will
clearly require copying the tags associated with a data page from
the virtual-indexed tag storage the VM system maintains to the
physical-indexed working memory when a virtual page is given physical
memory, and back to the virtual-indexed store to preserve them when
that page's data is moved out to secondary storage and the physical
memory released for reuse. This also suggests that the storage
overhead of tagging is not limited to that required to store the
physical tags, the additional cost incurred by the VM subsystem to
store tags its way needs to be accounted for as well.
Assuming the previous paragraph makes sense to anyone I was wondering
if any consideration was given to instead having the hardware maintain
tags in storage indexed by per-process virtual address, perhaps with
the location of tag data in physical memory being determined by the
analog of a page table lookup. This dramatically changes the location
of the tag cache from where the memo's picture puts it (to a place
where you maybe don't want it) but would seem to provide an equivalent
service to software operating in process context with certain additional
advantages:
- It would allow tags to be accessed and updated by hardware in the
same page-sized, virtual-address-indexed chunks of storage that
the VM subsystem is likely to want to use to deal with them, avoiding
the extra overhead and copying involved in maintaining both virtual-
and physical-indexed tag data.
- When a process exits it would cleanly take its tags with it, rather
than leaving them in the physical-indexed storage to be cleaned up
prior to reuse.
- Virtual-indexed tagging might make hardware virtualization easier,
in that the same techniques used to virtualize page tables could be
applied to tag storage as well.
- Tags could be write-protected (or not) separately from the data.
That is, you could have read-only data with writeable tags or
writeable data with read-only tags. I have no idea if this is
useful or not.
- For some common uses of processor memory it isn't clear to me that
tags are useful. An example might be the filesystem buffer cache,
or memory being used for memory-mapped file I/O, where the processor
memory is being used as secondary storage for (tagless) on-disk
data. With physical indexing the unused tags for these locations
will still consume space in physical memory (and perhaps in the
cache as well) but with virtual indexing the tag storage could
perhaps be eliminated for memory whose use doesn't benefit from
them. Additionally, being able to determine that a memory location
is untagged very early might allow stores to be buffered without
the overhead of loading the tag for that location from memory first.
- I think having the tag cache, and the logic to associate tags
with the corresponding data, close to the processor (i.e. where
you'd need it to do virtual address indexing), rather than far
from the processor and close to the DRAM, is a more efficient
place to put it. The reason is that tags are more valuable than
data, so for best effect the fraction of the cache occupied by
tags should probably be greater than 2/66; tags are needed to
complete both stores and loads while data is only needed to
complete loads so tags are useful without the associated data.
The arrangement described in the memo, which widens cache words
and forces the processor to load a location's data if it wants
to see the associated tag forces cache occupancy by tags to
exactly 2/66 of the total as well as forcing stores, which are
only interested in tag values, to spend bandwidth uselessly
loading data into the cache that is immediately going to be
overwritten. This isn't an argument for virtual indexing of
tags, but is an argument that the tag cache implementation
required to support virtual indexing is probably more efficient
for other reasons.
- An interesting question might be, if a memory region is being
shared among and updated by several processes, are the tags set
by one process relevant to the others or is each process interested
only in its own? I think the answer to this might depend on what
the tags are being used for, but with physical-address-indexed
tag storage only one answer is possible while with virtual tagging
it can be done either way (i.e. the pages holding the tags for those
locations can also be shared by the processes, or each process
can have its own private version instead).
Having given this a whole half hour of thought I am no doubt missing
issues that might make me think otherwise, but virtual address indexing
of tag data seems like a way to achieve a more flexible end result
while better aligning the hardware support for tags with the most
likely way the software will want to deal with them.
Dennis Ferguson
8 years, 1 month
onchip SAR_ADC/DAC for analogue DAS
by sibu
Greetings
I read with great interest and its feels like best bit of computer news
since I studied computer architecture with AdaLovelace.
Here is my wish list for LowRisc:-
--that early versions of the device will comsider measurement and control
applications and incorporate circuitary for analogue-data manipulation Here
I am thinking of 16-20bit SAR/ADC and appropriate medium-speed DACs;
--that there will be early collaboration with the qemu group;
--that the planned prototype boards will implement coreboot.
Regards
SX
8 years, 1 month
Open GPU for the first CPU
by Ray Van De Walker
There -is- a mild-mannered alternative to arm-twisting a vendor for rights to a GPU. lowRISC could imitate Ruby Lee et al.'s PA-RISC multimedia ISA in a brownfield part of the RISC-V-ISA.Basically, it splits the integer ALU into 16-bit parallel channels, (it does "subword parallelism")and adds permuting, saturation and rounding options to the ISA.The articles say it speeds small integer tasks 40-50 fold. An 80mHz integer PA-RISC did full-motion video.Since it lives in the core, it leverages the machinery of the core: ALU, integer registers, caches, etc.
The article said it added 0.2% to the core area.
The approach is awesomely cheap, in silicon, design and validation, and it provides fast DSP as well as graphics.
If it's a reverse-engineered fresh design, it would be born open.Since it's small, it will not add much to the risk (i.e. it's low-risc...)Compiler extensions should be possible, so it could even leak into ordinary applications. Any RISC-V could adopt it and support pretty good graphics and DSP.(See the references of Multimedia Acceleration eXtensions - Wikipedia, the free encyclopedia;The IEEE articles are behind a pay-wall, but there seem to be copies of them here and there.)
| |
| | | | | |
| Multimedia Acceleration eXtensions - Wikipedia, the free encyclopediaThe Multimedia Acceleration eXtensions or MAX are instruction set extensions to the Hewlett-Packard PA-RISC instruction set architecture (ISA). |
| |
| View on en.wikipedia.org | Preview by Yahoo |
| |
| |
8 years, 2 months
Fabrication process
by Chris McGee
Hi All,
It’s really great to see progress on a clean and open sourced ISA. In theory, such an open source design could be altered and fabricated by anyone. However, if I had such a need I wouldn’t have any idea where to start.
I think that it would be interesting to have insight into the process, problems and solutions that you have experienced in the fabrication process for lowRISC.
Would you be willing to publish this kind of information so that others could follow in your footsteps?
Cheers,
Chris
8 years, 2 months
Open GPU for the first CPU
by Luke A. Guest
Hi,
I find the idea of a truly open platform a very interesting idea and I
have been thinking that LowRISC and other RISC-V implementors should
approach AMD for access to their Radeon GPU cores. By including this on
the SoC, it would allow developers to look into graphics as well as
other things as there needs to be a way of training the next generation
of graphics driver programmers at the university or home level. Also, by
doing this, a RISC-V+Radeon CPU could really kill off these other boards
with closed GPU's.
Just a thought, has anyone else considered this? I think before the
final RPi like boards are made, you should look into providing graphics
access and this could be a really good way of doing that.
Luke.
8 years, 2 months
Integrity of external memory
by Renaud Pacalet
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
I just discovered this exciting project. I'd be more than happy to
contribute if I can. I am doing some research in the hardware security
field, especially on integrity and encryption of external memories
(https://secbus.telecom-paristech.fr/). I saw that security will be an
important aspect of the lowRISC design and that memory tagging and
encryption are considered. Will there also be something about memory
integrity? I mean, something to defeat probing attacks, DMA injections
and all other kinds of attacks that tamper with the content of
external memories?
- --
Renaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEAREIAAYFAlSr6LUACgkQ6X2qPZD76M/yZACbBFJCbEolfF6QZDfd4wxhLsEd
xoQAni9fTB38L/VLFc51l+SfRmmcf0/e
=kmP2
-----END PGP SIGNATURE-----
8 years, 2 months
Mail about FlashROM
by Reinoud Zandijk
sorry for the inconvenience, but please read my message on the fabrication
process thread about my ideas about the FlashROM handling.
With regards,
Reinoud
8 years, 2 months
Re: [lowrisc-dev] Fabrication process
by Reinoud Zandijk
Hi folks, best wishes for 2015 :)
On Wed, Dec 31, 2014 at 09:33:39AM +0000, L.R. d S. wrote:
> >I think that it would be interesting to have insight into the process,
> >problems and solutions that you have experienced in the fabrication process
> >for lowRISC.
>
> As sr. McGee, I have the same think about this.
>
> Problems I see here: - How we can trust on crypto processor manufacturing?
...
> -The ROM's We will can compile everything from source and put it on ROM?
> Boads like BeagleBone have a ROM inside that can't be replaced (it's Mask
> ROM)... I hope this don't happen on lowRISC.
>
> -A method to make a write prottection on ROM? If so, we can compile,
> replace ROM, and then apply the write protection. With this we can trust on
> what we run, without the preocupation with deliberate third parties ROM
> write.
If its my call, i'd opt for a (serial) FlashROM to hold the more secure
firmware parts. In my design (see my other posts) this FlashROM can only be
accessed by the Minion side, and then even only by the `master' Minion that
boots, programs and guards the other Minions; this Minion can then also
reprogram the FlashROM if allowed to. If this FlashROM is also holding the
firmware of the `master' minion then the coverage is complete. As for
mechanisms for allowing such programming think of say a hardware switch to
indicate open-for-programming or specific settings in the boot
environmenti/Hypervisor. If the boot environment is then disallowing the
(re)programming it can be seen as walling of the Minion side for tampering
until another hardware reset.
This firmware on FlashROM could also provide the boot environment and the
Hypervisor. No OS can then mess with harddiscs/SDcards/whatever to create a
compromised boot environment while still allowing it to be updated later on.
> http://www.chesworkshop.org/ches2013/presentations/CHES2013_Session4_3.pdf
This is a very scary trend yes if its that pervasive; phew... wel we could
create error-detecting/correcting logic in it but i expect that to be a bit
out-of-reach now. Better stick to software encryption for now i'd say.
With regards,
Reinoud
8 years, 2 months
