profile
viewpoint

chipsalliance/Cores-SweRV 351

SweRV EH1 core

chipsalliance/Cores-SweRVolf 74

FuseSoC-based SoC for SweRV EH1

chipsalliance/Cores-SweRV-EL2 54

SweRV EL2 Core

olofk/corescore 23

CoreScore

fusesoc/sd_device 8

SD device emulator from ProjectVault

kactus2/pulpinoexperiment 4

IP-XACT packaging of Pulpino by pulp-platform.org: https://github.com/pulp-platform/pulpino

olofk/cryptech-cores 4

Core description files for the Cryptech project

PR opened olofk/serv

break out verilator fileset for use with v < 4.030

Ensure vlog_tb_utils is not included in the file-set for verilator runs. Verilator versions < 4.030 do not implement dumpfile and dumpvar, which are used in vlog_tb_utils.

+9 -4

0 comment

1 changed file

pr created time in 4 hours

issue commentlibrecores/librecores-web

How do I delete a project I submitted to LibreCores?

This project is now deleted.

ShashankVM

comment created time in 5 hours

startedolofk/serv

started time in 5 hours

issue commentlibrecores/librecores-web

How do I delete a project I submitted to LibreCores?

https://www.librecores.org/ShashankVM/stack-systemverilog

Thank you, @imphil

ShashankVM

comment created time in 10 hours

issue commentlibrecores/librecores-web

How do I delete a project I submitted to LibreCores?

Unfortunately, deleting projects is currently only possible through us. Please let us know which project we should delete and we'll do that for you.

ShashankVM

comment created time in 11 hours

fork mtnrbq/serv

SERV - The SErial RISC-V CPU

fork in 16 hours

fork luke-mckay/uart16550

UART 16550 core

fork in a day

issue closedchipsalliance/Cores-SweRV

question about adding custom instructions

hi, l saw some infomation in README.md .:"If adding/removing instructions, espresso must be installed (used by tools/coredecode)". Can this increase the custom instructions ,and how to use this script .

closed time in a day

feiger313

issue commentchipsalliance/Cores-SweRV

question about adding custom instructions

thank you for your help

feiger313

comment created time in a day

push eventfossi-foundation/wishbone

imphil

commit sha 8b7c28001275e9b72a0cb38658d97e7e38c23323

deploy: 3d678af8684bb234a88e4bbbe151efb92617940d

view details

push time in a day

push eventfossi-foundation/wishbone

Philipp Wagner

commit sha 3d678af8684bb234a88e4bbbe151efb92617940d

Use www subdomain for CNAME This works much better for GitHub pages and avoids cert errors.

view details

push time in a day

issue openedolofk/fusesoc

Iterative dependency resolution

FuseSoC currently does one (and after #391 two) dependency resolution runs, and expects to be able to fully resolve all dependencies in that run.

With generators adding dynamicity to the picture, we should be looking into an iterative dependency resolution as long as new information becomes available.

What I'm looking for is an algorithm like this:

core_db = collect_core_files()
dep_tree = solve_dependency_tree(core_db, entrypoint)

while (True):
	# Perform all operations which might produce new cores
	changed = False
	generators = get_generator_list(dep_tree)
	for g in generators: 
		new_cores = run_generator_and_get_new_cores(g)
		if new_cores:
			core_db += new_cores
			changed = True	

	# In the future: Expand to look at certain remote locations for new cores
	
	# Resolve dependency tree again to take new information into account.
	dep_tree_before = dep_tree
	dep_tree = solve_dependency_tree(core_db, entrypoint)
	if dep_tree_before == dep_tree:
		break

if not is_completely_resolved(dep_tree):
	exit("Unable to resolve all dependencies.")

This algorithm isn't guaranteed to stabilize, so we need to add additional exit conditions, e.g. abort after n tries. Equally, there is room for some optimization (e.g. avoid the second resolution if generators didn't produce new cores).

Use cases for this new approach:

  • Cores can depend on cores which are produced by a generator, but don't exist anywhere else. This is actually something we're likely to need in OpenTitan, and effectively solves #235 through generators (more on that once I've finished thinking about it).
  • We can expand the search scope step-by-step. For example: First, only search local cores, then also search cores in a certain remote location (librecores!). This will keep dependency resolution fast for local use cases.

created time in 2 days

fork amamory-ursa/fusesoc

Package manager and build abstraction tool for FPGA/ASIC development

fork in 2 days

fork wtfuzz/wb_intercon

Wishbone interconnect utilities

fork in 3 days

push eventfossi-foundation/wishbone

imphil

commit sha a89e6ec5bffb26353fa7cb1ef2e29818f8f0c6e2

deploy: fcf5d95bccee4511c6d555777ebb2e08e34dc513

view details

push time in 3 days

push eventfossi-foundation/wishbone

Philipp Wagner

commit sha fcf5d95bccee4511c6d555777ebb2e08e34dc513

Build web site through GH actions

view details

push time in 3 days

create barnchfossi-foundation/wishbone

branch : gh-pages

created branch time in 3 days

push eventfossi-foundation/wishbone

Philipp Wagner

commit sha d6961570e2ca7349e8a5b270e1035fc6d8b7b7f2

Build web site through GH actions

view details

push time in 3 days

push eventfossi-foundation/wishbone

Philipp Wagner

commit sha de04c64c2362c119ed9dec6f3cad8927bbe63434

Build web site through GH actions

view details

push time in 3 days

push eventfossi-foundation/wishbone

Philipp Wagner

commit sha c671d2dadfce070bf4d3881bdc05306d70d9c69f

Build web site through GH actions

view details

push time in 3 days

delete branch olofk/fusesoc

delete branch : ci-gh-actions

delete time in 3 days

pull request commentchipsalliance/Cores-SweRV-EL2

Fixes in riviera support which was pushed onto 1.3 version

@danielmlynek, it is perfectly OK to request changes. If they are reasonable and compatible with our toolsets, they will be considered for merging. We do run LEC on all requested RTL changes that do not modify the functionality or fix bugs.

Thank you for your contributions.

danielmlynek

comment created time in 3 days

pull request commentchipsalliance/Cores-SweRV-EL2

Fixes in riviera support which was pushed onto 1.3 version

Please, do not ask to change not essential or style related things.

Some simulators hangs on orginal code - that is why I've requested this change.

danielmlynek

comment created time in 4 days

startedolofk/ipyxact

started time in 4 days

startedolofk/fusesoc

started time in 4 days

startedolofk/edalize

started time in 4 days

pull request commentchipsalliance/Cores-SweRV-EL2

Fixes in riviera support which was pushed onto 1.3 version

Hi Daniel,

Did the original RTL code cause any simulation/synthesis problem?

All our simulation/synthesis tools did not flag this. Furthermore, this coding style is recommended by Synopsis as less prone to infer unwanted latches in combo logic.

The code represents combinatorial logic which is by definition glitchy and there are other pieces of glitchy logic in the core. I've never heard that combo logic in RTL cause any deadlocks ..

Please, do not ask to change not essential or style related things.

danielmlynek

comment created time in 4 days

pull request commentchipsalliance/Cores-SweRV-EL2

Fixes in riviera support which was pushed onto 1.3 version

Why do you change RTL? Initializing signal to default value at the begining of process may lead to glitches an in this case it cause deadlock between proceses

RIVIERA variable in Makefile is not used - why to change? That is true. There was a typo so Ijust have fix it. This variable can be removed or may be used to define name of riviera compilation/simulation program. Let me know if I should open PR to fix it.

Why to change what is deleted by make clean ? Don't create work directory where you run simulations ... "work" was dublicated so I've removed the 2nd its occurense from make clean list.

danielmlynek

comment created time in 4 days

more