asb

10 ms·

61.
by asb 9y ago
It's 50TB/month, not unmetered. Only 1.17EUR/TB over that though.
62.
by asb 9y ago
It's not something we've worked on so far at lowRISC. If SiFive have been working on something in that area I haven't seen them talk about it publicly. Sounds like a great project, if you do start working on it I'd love
63.
by asb 9y ago
Hi, I'm one of the co-founders of the lowRISC project. You're right that SiFive's licensing arrangements can be somewhat confusing. Although they sell licenses (like https://static.dev.sifive.com/business&#x2F
64.
by asb 9y ago
I'm struggling to understand the intended meaning of this comment "In addition, when there is a document they can refer to, individual contributors (ICs) can be given concrete feedback on performance if important decisions which a
65.
by asb 9y ago
There's been some discussion about bitfield access optimisation in the LLVM community. This RFC thread may be interesting to you http://lists.llvm.org/pipermail/llvm-dev/2017-March/110895.h... . If you en
66.
by asb 9y ago
This is an understandable assumption, but it's actually not the way it works. I'm sure the Dutch tax authorities have equivalent documentation, but the UK description of the 'reverse charge' should explain the basic prin
67.
by asb 9y ago
The announcement on Reddit also says they are changing their privacy policy to remove support for 'Do Not Track' https://www.reddit.com/r/announcements/comments/6qptzw/with_...
68.
by asb 9y ago
As the author of LLVM Weekly I'd like to thank you for spreading the word. I'm glad you find it useful.
69.
by asb 10y ago
I'd be really interested in a write-up of how you use and process feedback.
70.
by asb 10y ago
Site responsiveness, though they're working hard in that.
71.
by asb 10y ago
Can anyone contrast this new (rebooted?) containerd to rkt?
72.
by asb 10y ago
If you do find the time, count me in as being very interested in seeing the proposal for growing/shrinking Go stacks.
73.
by asb 10y ago
Related to this discussion, this talk on user-scheduled OS threads is really interesting. It's a shame no proposed implementation or experimental patches have appeared https://www.youtube.com/watch?v=KXuZi9aeGTw
74.
by asb 10y ago
Interesting, could you say more about your desire for 1:1 threading in Go? Do you feel that there are few users who need a huge number of goroutines, or that 1:1 is sufficiently lightweight for many of those users?
75.
by asb 10y ago
You might also be interested in my notes from the event: http://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-da... http://www.lowrisc.org/blog/2016/11/fifth-risc-v-worksho
76.
by asb 10y ago
SiFive haven't completed development of their Linux-capable platform (and we haven't completed ours). We both make use of the Rocket codebase. Key differences include our support for tagged memory and minion cores. Funding so far
77.
by asb 10y ago
I've added a link on the 'about' page, in addition to the link that was already there on 'community'. A future restructuring will make it more prominent in the top-level navigation.
78.
by asb 10y ago
I think we need to do more work to demonstrate the advantages of tagged memory to potential adopters. I hope that the cost/benefit ratio will be such that others will adopt it. As for other improvements, it's difficult to pick out
79.
by asb 10y ago
Our initial use case (real-time and programmable I/O) is very similar, so yes.
80.
by asb 10y ago
I'd recommend looking at Nyuzi https://github.com/jbush001/NyuziProcessor . A GPU is an obvious future step, but there's a lot to be done before that.
81.
by asb 10y ago
Assuming sufficient die area on a 28nm test chip, we would like to have a heterogeneous cluster with something like 2xBOOM and 2xRocket.
82.
by asb 10y ago
That article mentions FPGAs, but doesn't discuss any of the issues with taping out an ASIC design. Specifically, the use of a proprietary and highly commercially sensitive process design kit, and the likely need for other IP to make a
83.
by asb 10y ago
On-chip, not in the near future. The main challenge is the analogue design and that's not the area where our expertise lies. The economics are also quite different for an open source effort (digital logic is portable across different p
84.
by asb 10y ago
Take a look at http://fossi-foundation.org/ . Whatever terminology you're using, I think it's right to say lowRISC and FOSSi have a shared vision for free and open source designs that respect user freedom.
85.
by asb 10y ago
I've tried to answer that question here https://news.ycombinator.com/item?id=13130195
86.
by asb 10y ago
The GPL family of licenses are complex legal instruments which really don't apply in a sensible way to chip designs. LGPL has previously been used in the OpenRISC community, but the 'library' boundary isn't really clear
87.
by asb 10y ago
This is true, imaging a die can help but it's not enough for full assurance. See e.g. this work on inserting hardware trojans through changing the dopant levels on transistors http://sharps.org/wp-content/uploads&#
88.
by asb 10y ago
Yes, we're behind where we initially thought we could be. When we first started, we hoped we might produce a test chip in 2016. This hasn't happened. One major factor is it's been difficult to grow our team. Finding people wi
89.
by asb 10y ago
Everything is up at https://github.com/lowrisc . We recently had a website redesign which is 'soft launched' (in that there are a number of regressions like this I need to sort out). Amongst other pieces of IP, we
90.
by asb 10y ago
For the initial iteration of minion cores, think of them as being an openly documented boot core and a way of implementing low-speed I/O in software (with some extra hardware support for things that would be dumb to do in software, e.g

More ›