Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rtl] remove redundant prog_buf #1030

Merged
merged 1 commit into from
Sep 23, 2024

Conversation

NikLeberg
Copy link
Collaborator

Just found this signal that is completely redundant. I kinda remember us having found that and removing it a few months ago... did it creep back it? 🤔

Unrelated: I'm playing around with implementing system bus access for the DM. Is that something you would accept a PR for?

@stnolting
Copy link
Owner

Just found this signal that is completely redundant.

You're right!

I kinda remember us having found that and removing it a few months ago... did it creep back it?

I can't remember... 😅

Unrelated: I'm playing around with implementing system bus access for the DM. Is that something you would accept a PR for?

It has been some time since I have dealt with the debug-spec... Correct me if I'm wrong, but the system bus access allows the debugger to directly access the entire address space without going through the CPU, right?

To be honest, I do not see any benefit here (except for speed improvements). Furthermore, this would require another host interface for the bus system increasing area consumption. 🤔

@stnolting stnolting added HW Hardware-related cleanup Clean-up the codebase labels Sep 22, 2024
@stnolting stnolting merged commit a155572 into stnolting:main Sep 23, 2024
7 checks passed
@NikLeberg NikLeberg deleted the dm/cleanup_progbuf branch September 23, 2024 11:09
@NikLeberg
Copy link
Collaborator Author

To be honest, I do not see any benefit here (except for speed improvements). Furthermore, this would require another host interface for the bus system increasing area consumption. 🤔

You were right. Got it working and the test for my cosim_jtag project merely runs 10 seconds faster. Still a 10% improvement, but not worth the area increase.

@stnolting
Copy link
Owner

Got it working and the test for my cosim_jtag project merely runs 10 seconds faster. Still a 10% improvement, but not worth the area increase.

That's more than I have expected! 😅

Did you do some synthesis experiments? Can you say something about logic utilization and critical path / f_max impact?

@NikLeberg
Copy link
Collaborator Author

I pushed the changes to a branch on NikLeberg/neorv32. It is very much WIP, unoptimized and potentially likely containing bugs.

without SB with SB
Logic Cells (only DM) 387 638 +251
Registers (only DM) 243 363 +120
f_max [MHz] 70.79 69.29 -0.15

My f_max is generally very slow, as I'm synthesizing for an old Cyclone IVE where 80 MHz would be the theoretic maximum if you optimize it down to the logic element. I usually run it at 50 MHz.

@stnolting
Copy link
Owner

That is just the modified DM, right? So without the additional bus mux?

Does f_max show the critical path of the DM or of the entire processor?

@NikLeberg
Copy link
Collaborator Author

Aah, right, forgot to include the muxes logic cell count...

But f_max is of the entire processor and propably caused by the additionally required bus mux.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Clean-up the codebase HW Hardware-related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants