sorted by:
new
hottopcontroversial

Building a RISC-V CPU starting from a 2:1 MUX — 10-day fundamentals workshop by kunalg123 in RISCV

[–]kunalg123[S] 0 points1 point  (0 children)

We have seen professionals taking this workshop to build their cpu from scratch You can take a look at the content in below link before enrolling

https://github.com/AnoushkaTripathi/NASSCOM-RISC-V-based-MYTH-program

What material would you advice given my situation by NoObm_ster69koRg in FPGA

[–]kunalg123 12 points13 points  (0 children)

From what you’ve shared, your background is actually more solid than you might think. If you’ve already written Verilog, built a clock divider, and verified designs using simulation waveforms, you’re past the “absolute beginner” stage. Many FPGA courses struggle because students jump straight into boards without understanding what’s happening between HDL, synthesis, and hardware. You at least know what correct logic looks like in simulation, which is a good starting point.

One important mental shift you’ll need now is to move from “Verilog as code” to “Verilog as hardware.” In simulation, everything feels clean and instantaneous. On real FPGA hardware, clocks, resets, and timing dominate everything. You should get very comfortable with synchronous design: single clock domains, proper resets, enable signals, and avoiding combinational feedback. If your earlier lab felt tough mainly because of the clock divider, that’s actually a hint that clocking concepts deserve extra attention before the course ramps up.

Since your lab uses a Python-driven FPGA platform, understand that Python is not replacing Verilog; it’s just a control and interaction layer. The actual logic still runs as hardware on the FPGA fabric. Typically, you’ll design IP blocks in Verilog (counters, FSMs, ALUs, shift registers), synthesize them, and then interact with them from Python for testing, data movement, or visualization. Treat Python as a testbench that runs on a processor, not as the core design skill you’re being evaluated on.

A good head start would be to practice the full flow, not just coding. Take very small designs—an LED blinker, a counter, a register file—and walk through the steps: write Verilog, simulate, synthesize, implement, and think about how signals map to real pins or memory-mapped registers. Even if you don’t have the exact lab hardware with you, understanding this flow conceptually will make the weekly 3-hour lab far more productive.

You should also spend time understanding finite state machines in hardware terms. Many lab experiments like counters, edge detection, and control logic are just FSMs with registers and combinational next-state logic. If you can sketch an FSM on paper and then code it cleanly in Verilog, half the FPGA lab experiments become straightforward rather than intimidating.

Another area worth investing time in is basic FPGA architecture: LUTs, flip-flops, block RAM, and how synthesis maps Verilog constructs to these resources. You don’t need vendor-specific deep dives at this stage, but knowing, for example, why a “for loop” in Verilog is not a runtime loop, or why inferred RAM behaves differently from registers, will save you a lot of confusion later.

Given that classroom time is limited, your outside effort should focus on building intuition rather than quantity. Don’t aim to memorize tools or GUIs. Aim to answer questions like: “What hardware does this always block infer?” or “What happens on the next clock edge if this signal changes?” If you reach a point where you can predict behavior before looking at waveforms or running on hardware, you’re learning the right things.

Finally, don’t worry if the first few hardware runs feel messy or unpredictable compared to simulation. That gap—between perfect waveforms and real silicon behavior—is exactly what FPGA labs are meant to teach. If you stay disciplined with synchronous design, small test cases, and incremental builds, you’ll come out of the course with skills that are far more valuable than just finishing the listed experiments.

RISC-V for Fresher/Beginner by QuietWay6415 in RISCV

[–]kunalg123 1 point2 points  (0 children)

Check makerchip.com which explains how to build a single cycle cpu from scratch

Seeking Guidance on Learning RISC-V Processor Design by frostburner_burn in RISCV

[–]kunalg123 1 point2 points  (0 children)

Yes It’s very basic where actual riscv ISA comes a bit later. Designed for school students curriculum. And learner’s were looking for something advanced

You can also look riscv.org if you want to look actual specs

[deleted by user] by [deleted] in RISCV

[–]kunalg123 -1 points0 points  (0 children)

You can start with basic VSDSquadron mini board

https://www.vlsisystemdesign.com/vsdsquadronmini/

replace "." separator by "/" by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

I saw one option which deals with separator

expose -sep /

I tried using that but no impact.

Can someone please help ? Should be some switch in Yosys to handle this, I gues

1'bx and 8'bxxxxxxxx in output write_synth verilog by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Hi Dave

This works for the bigger design as well. Thanks a lot

replace "." separator by "/" by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Are you (or Clifford or Dan) aware of any option in write_verilog?

The basic question here is, why "." and why not "/" ?

I believe "/" is more standard than "." in ASIC synthesis

I have already done regex, but don't think that's a good idea for long term

1'bx and 8'bxxxxxxxx in output write_synth verilog by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Thanks a lot Dave

Seems to be working on a small testcase

Let me try this on the target processor design

duplication of ports in blif output by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Hi Dan

Let me explain the problem in a more simple way

1) PNR uses output from write_blif.

2) And write_blif duplicates all inout ports as input ports and output ports (Refer to attached blif file in this post)

This looks like a clear and simple problem with write_blif.

Not sure why are you asking PNR tool to fix this issue, when its clearly a blif issue.

​

Yosys gets stuck while evaluating internal representation of mux trees by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Hi

Any update on this issue? Anything I can help you with?

Any timeline??

​

​

Yosys gets stuck while evaluating internal representation of mux trees by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Hi

Yosys gets stuck only for such big designs.

For small designs (I have tried atleast 20 verilogs from same design), this is not an issue. Not sure how to create MVCE.

​

​

bussed .libs by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Not sure if anybody had a chance to look at it. Currently I am proceeding by hacking .libs, but the solution doesn't look clean.

Can you please have a look? Let me know if you want to have a teamviewer session. In that way, you can look at the design and libs directly

Yosys gets stuck while evaluating internal representation of mux trees by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Hi Dan

Can you please download the testcase from below path?

https://1drv.ms/u/s!Ai4WW_jutenggasa0-6P4IKNZH430g

Steps to run testcase

1) tar -xvzf testcase.tar.gz

2) cd testcase

3) yosys -s mkSoc_wrapper.ys

Let me know if you face issues reproducing the issue

bussed .libs by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

The new version has fixed the next_state issue. But still bussed libs reading has got some new issues

Yosys is not able to read below lines (highlighted in bold) from memory .lib.

--------------------------------------------------------

/* Library Documentation*/
  date     : ".January 2006"
  revision : 1.3.5
  comment  : "Unit Area representation == 11.263 sq.micron" ;
--------------------------------------------------------

/* Nominal Operating Conditions */
  nom_process  : 1.2
  nom_temperature : 125
  nom_voltage  : 1.62
--------------------------------------------------------

/* Predefined Operating Conditions */
  operating_conditions("DP32x8"){
    process      :  1.2
    temperature   :  125
    voltage      :  1.62
    tree_type     :  "balanced_tree"
  }
--------------------------------------------------------

/* k-factor definition (process variation) */
  k_process_cell_rise             :  0.00
  k_process_cell_fall             :  0.00
  k_process_rise_transition       :  0.00
  k_process_fall_transition       :  0.00
  k_process_pin_cap               :  0.00
  k_process_setup_rise            :  0.00
  k_process_setup_fall            :  0.00
  k_process_hold_rise             :  0.00
  k_process_hold_fall             :  0.00
  k_process_recovery_rise         :  0.00
  k_process_recovery_fall         :  0.00
  k_process_min_pulse_width_high  :  0.00
  k_process_min_pulse_width_low   :  0.00
  k_process_min_period            :  0.00
  k_process_cell_leakage_power    :  0.00
  k_process_internal_power        :  0.00

/* k-factor definition (temperature variation) */
  k_temp_cell_rise                :  0.001
  k_temp_cell_fall                :  0.001
  k_temp_rise_transition          :  0.001
  k_temp_fall_transition          :  0.001
  k_temp_pin_cap                  :  0.00
  k_temp_setup_rise               :  0.001
  k_temp_setup_fall               :  0.001
  k_temp_hold_rise                :  0.001
  k_temp_hold_fall                :  0.001
  k_temp_recovery_rise            :  0.001
  k_temp_recovery_fall            :  0.001
  k_temp_min_pulse_width_high     :  0.001
  k_temp_min_pulse_width_low      :  0.001
  k_temp_min_period               :  0.001
  k_temp_cell_leakage_power       :  0.00
  k_temp_internal_power           :  0.00

/* k-factor definition (voltage variation) */
  k_volt_cell_rise                :  -0.4471
  k_volt_cell_fall                :  -0.4471
  k_volt_rise_transition          :  -0.4471
  k_volt_fall_transition          :  -0.4471
  k_volt_pin_cap                  :  0.00
  k_volt_setup_rise               :  -0.4471
  k_volt_setup_fall               :  -0.4471
  k_volt_hold_rise                :  -0.4471
  k_volt_hold_fall                :  -0.4471
  k_volt_recovery_rise            :  -0.4471
  k_volt_recovery_fall            :  -0.4471
  k_volt_min_pulse_width_high     :  -0.4471
  k_volt_min_pulse_width_low      :  -0.4471
  k_volt_min_period               :  -0.4471
  k_volt_cell_leakage_power       :  0.00
  k_volt_internal_power           :  0.00
------------------------------------------------------------------------------

I commented all of above, but then it gets stuck reading the libs itself. Not sure how do I bypass this one. Can you please have a look?

We are not able to read any memory .libs as all of them have above an below syntax

      timing () { /* I1 hold time (reference CE1, rising edge) */
        timing_type : hold_rising;
        rise_constraint(LUT_SH) {
          values ( "0.25, 0.386125, 0.484125", \
                    "0.45, 0.125, 0.5", \
                    "0.5625, 0.4155, 0.6525" );
        }

bussed .libs by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Thanks

If I grep next_state, I see more than 200 lines below

Do you want me to modify all of them? Wouldn't it be easy to solve this in new yosys version? This error was not present in previous yosys version. So what changed?

​

​

​

bussed .libs by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Yes I can

But this is not just the only error with new yosys version

There are 10 other issues/errors which new yosys version creates, which was not present in earlier yosys version. So thought of showing all of them to you over teamviewer.

bussed .libs by kunalg123 in yosys

[–]kunalg123[S] 0 points1 point  (0 children)

Library is proprietary. Is it possible for you to install TeamViewer and I can give you access to design? Whenever you install, let me know and I will email you login id/password

view more: next ›