https://open-source-silicon.dev logo
Join Slack
Powered by
The clock is randomly dropping out
# clear
m
The clock is randomly dropping out
m
Hmm... I remember that caravel in early MPW runs had clock tree issues - maybe something similar is happening here? https://groups.google.com/g/skywater-pdk-users/c/tRlFm_rSOJ8?pli=1
m
The caravel core is fine but the output of synthesized clocked FPGA design is acting very strangely
m
I'm curious in practice how does the hacked-on programming by FTDI powered JTAG required due to the block order screwup works... Do you remove jumpers 1-6 after programming or something?
I'm just wondering if something about that extra circuity might be causing some flakiness
m
I am programming the bitstream using firmware
It is very slow
m
Okay... yeah that must be fun
m
Those jumpers are not easily swapped. They are solder bridge type jumpers. I would have to cut the trace in the middle to open the jumper and solder them to close the jumper.
The bridged management gpio have to be configured to not contend
m
Oh okay - I've not seen a high rez picture of the board so I was not sure - I see now the symbol difference on the schema though
m
image.png
this is how the other examples do it
image.png
the 
process_bit_stream(fpga_pwm8_size, fpga_pwm8);
is very slow
m
interesting... so some of the pinout mappings appear to be different from SOFA HD it appears https://skywater-openfpga.readthedocs.io/en/latest/_images/sofa_hd_fpga_io_switch.svg
m
I was going by the readme
m
Actually no they align I think
m
Copy code
+set_io pwm gfpga_pad_io_soc_out[122]
+set_io duty[0] gfpga_pad_io_soc_in[48]
+set_io duty[1] gfpga_pad_io_soc_in[49]
+set_io duty[2] gfpga_pad_io_soc_in[50]
+set_io duty[3] gfpga_pad_io_soc_in[51]
+set_io duty[4] gfpga_pad_io_soc_in[52]
+set_io duty[5] gfpga_pad_io_soc_in[53]
+set_io duty[6] gfpga_pad_io_soc_in[54]
+set_io duty[7] gfpga_pad_io_soc_in[55]
what the clock should be in the PCF is not clearly stated anywhere
I simplified the PWM design a bit
m
From the image above FPGA Core CLK should be connected to Caravel GPIO 36 if it was not changed from SOFA HD
PROG_CLK is GPIO 37 in both so it's highly likely it is I think
m
the PCF numbers are not the same as the caravel IO numbers
I tried 36
oh I see something on the SVG
GPIO[25] toggles between LA and wishbone
m
Yep thats how I read it too
Maybe WB causing contention?
m
maybe
looks like GPIO25 is parked at GND
mprj_io[25] =	FPGA IO[126]
this is conflicting information
Copy code
// Connecting the Fabric IO 47 to 118 to the LA_out: 127 to 56
    // MS: Disconnect the WBS bus dat_o lines
    generate 
        for(i=0; i<=71; i=i+1) begin
            assign gfpga_pad_io_soc_in[47+i] = la_data_in[127-i];
            assign la_data_out[127-i] = gfpga_pad_io_soc_out[47+i];
        end
    endgenerate
there is no mux on this design
m
Okay... the fabric dimensions are different between SOFA HD and CLEAR as well so I would assume that at least some of the GPIO mappings are different too
m
yeah
m
Just got my boards (I ordered two for reasons) and when cloning the CLEAR repo just now I noticed this in the README.MD:
So A) 36 should be the clock (same as SOFA HD) and B) 35 should be a selector to connect it either to caravel or clock it externally
Also from naming used it suggests to me that wishbone clock line is being used as the link into the caravel clock - while the rest of the bus lines have been cut off per your snippets above
m
It never says what to put in the PCF file for the clock.
I took out the pin definition for clock and it is somehow inferred
With the wishbone 10mhz clock I found that a 32bit counter misbehaves
😢 1
m
The way they have embedded vtr and yosys/abc into the openfpga repo I would not be surprised if there is some sort of magical clock mapping injection
m
Make sure you only have one clock domain is what that sounds like to me
7 Views
Open in Slack
PreviousNext
Powered by