rob at landley.net
Sat Aug 26 02:46:27 EDT 2017
On 08/25/2017 04:25 PM, emanuel stiebler wrote:
> On 2017-08-10 17:11, Rob Landley wrote:
>> On 08/09/2017 04:55 AM, D. Jeff Dionne wrote:
>>> On Aug 9, 2017, at 08:29, emanuel stiebler <emu at e-bbes.com> wrote:
>>>> Hi all,
>>>> watched the video on yutube, from rob & jeff on the embedded linux
>>>> conference, and thought it is pretty exciting. But, being new to
>>>> j-core have some questions, and couldn't find the answers easily in
>>>> the archives ...
>>> Thanks. We should put up some FAQs...
>> I have a bunch of website stuff queued up for when we manage to dig back
>> down to this...
>>>> a.) are the source now in GIT, somewhere on github?
>>> We have not done a release in a while. Not because we stopped,
>>> rather the opposite (customer deliverables).
> So, the:
> is the latest?
Latest we've published, yeah.
We have a 62.5 mhz version with cache updates and such that we need to
break out and upload, which should just take a couple days but it's
about 12th on any individual's todo list.
And we've had more than one engineer take a stab at breaking the open
source code out from the proprietary code and do a full history upload
we can rebase on top of (so our development would be live from that
point on), but the repo history is a mess going back to 2012 and we've
changed our strategy on how we want to convert it more than once.
Internally soc_top is a set of ~30 nested mercurial repositories mixing
proprietary stuff with open source stuff. The existing release tarballs
were sanitized by hand, but that's a stopgap and we want the whole
history up on github. We've gone back and forth between merging the
mercurial repos into one big git repository, or trying to make git
subtrees work. I think the current plan (for the next attempt) is subtrees.
We _sort_ of have a modular build design that let you treat the SOC as a
set of discrete components that slot together like legos. Except you
can't in reality, and the whole thing desperately needs a config system
(various makefile targets have been implemented by hand; it should be
automated and selectable), and there's layers of build dependencies you
have to install depending on what you enable, and we have a whole build
system revamp we want to do to make the modular build design goal
_actually_ the case. (Which also helps with the ASIC since that has to
be validated by the fab in discrete chunks, but that got bumped back by
~6 months because we needed to pull the engineers off to do other stuff
for customers with nearer deadlines first.)
(We've been dealing with a whole lot of chicken-and-egg circular
dependencies getting stuff out the door for a year now. We need to
quadruple our staff size but doing so means we'd take Brooks' Law in the
> But it looks, likes it contains "just" the SOC, not all the tools which
> are needed to generate new SOC, add new opcodes etc ...
See "layers of dependencies", above.
Some of the VHDL is generated. The instruction set is stored in an
openoffice spreadsheet (really!) which is parsed by a library and fed to
Lithp code running on leingen (which is an unholy amalgam of cloture and
java), and that generates the instruction parser code. Then other bits
are run through a preprocessor implemented in perl (basically adding a
couple features to the VHDL language)... It should all be in the README.
Building an existing config doesn't require installing most of that
(just the xilinx ise webpack toolchain and sh2 cross compiler, and
really we could remove the cross compiler requirement by shipping the
boot ROM binary, but haven't) because we shipped it with a lot of
generated files. But if you change the instruction set in the
spreadsheet you need all the dependencies installed.
If we ever get breathing space I'll try to sit down Jeff and a couple
lapel mikes and screen capture software, and have him explain it all to
me again, and we can post that on youtube. But that's somewhere _below_
12th on anybody's todo list. :)
Right now, we're trying to ship boards to customers...
More information about the J-core