<karimyaghmour> It looks like some of these are 130nm ST process.
<karimyaghmour> I suppose despite the node size being the same that that work can't be reused as-is.
karimyaghmour has quit [Ping timeout: 256 seconds]
karimyaghmour has joined #skywater-pdk
karimyaghmour has quit [Ping timeout: 256 seconds]
<tnt> So when OpenRAM says "WARNING: takes a long time", they mean it :p
<tnt> ** Characterization: 23719.8 seconds
m_w has joined #skywater-pdk
m_w has quit [Ping timeout: 256 seconds]
karimyaghmour has joined #skywater-pdk
m_w has joined #skywater-pdk
m_w has quit [Ping timeout: 244 seconds]
<mithro> 6.5 hours?
<mithro> That actually sounds a bit fast...
<tnt> This was a 64 words x 32 bits RAM only (2 ports, 1 R + 1 W).
<tnt> (and single typical operating point, not doing all the process corners).
<mithro> That sounds about right then
<tnt> I need to find how to get OpenRAM to include the multi-thread directive. I have ngspice enabled for multi-core but it need to be enabled in the source file.
<daveshah> there are even some GPU-based simulators out there
<daveshah> although I don't know how they compare to multi-threaded CPU compute
<tnt> Yeah I saw cuspice too, that's the next step.
<daveshah> nice
<mithro> xyce would be a good target to try
<mithro> @tnt You were asking about the code which generates those verilog files -> https://github.com/google/skywater-pdk/pull/61/files
<mithro> @tnt I wouldn't say it's great code -- deadlines and everything
<tnt> xyce ? You mean instead of ngspice ?
<tnt> Ah yeah, I'll have a look at those scripts, tx.
nickoe has joined #skywater-pdk
m_w has joined #skywater-pdk
<mithro> nickoe: You want a todo list? :-P
karimyaghmour has quit [Ping timeout: 264 seconds]
<nickoe> mithro: Also, I was a bit curious about the shuttle. Youbmentioned thatvall design would be acompanied by a riscv etc, but how does that work? Do we get template or some environment to be able to do pre silicon verification?
<mithro> nickoe: Basically it's a "harness"
<nickoe> mithro: What does this mean? Is it something that could be part of the final desing, or is it only intended for debugging?
<nickoe> mithro: mmm, the Mega Project is the part that people are to design, right?
<mithro> Yes
<nickoe> I have worked with VHDL and Verilog before for very simple projects (using xilinx ISE and vivado), but that is about all I know.
<mithro> nickoe: You can think of it as having a CPU with a bunch of GPIO and analog pins you can connect to the internal of your megaproject so you can set up / control / debug your IC
<nickoe> I once attempted to create an UART, I sorta failed at that then I tried to use some open desings, but I certainly never got anything working after poking at that a few days.
<mithro> There is plenty of "non-ASIC" related work to do in the tooling space
<mithro> Things like improving the generated documentation and similar
<nickoe> Is the IO there as is, or are there more pads available?
<mithro> nickoe: A user will get roughly 40ish IO
<mithro> s/user/mega project/
<mithro> The idea with the management region is that you might want to fit like 5 projects into the mega project space and have muxes between the IO pins which let you switch which project is active
<nickoe> What about JTAG for such a thing? I saw in your slide that a D flip flop seemed to be connected to a debug chain of some sort. Is that a thing?
<nickoe> mithro: Ahh, cool, I didn't get that impressions. But does that mean you consolidate those 40 projects into say eight chips?
<nickoe> So when you get a chip, you get a chip with somone elses design in it as well?
<mithro> nickoe: You could have internal jtag via the harness, or you could have it just connected to some pins
<nickoe> mithro: I wonder if azonenberg will submit something, he is a verilog wizard
<nickoe> mithro: I am sure I lack a lot of basic experince to even make anything remotely useful for this, but I sort of lack a template to work out from, and an overview of the toolchain, in the way that I don't know how far the PDK touches pre tapeout tests.
<nickoe> But I am sure you are working on that already :)
<mithro> nickoe: Have you tried something like https://github.com/litex-hub/linux-on-litex-vexriscv ?
<mithro> @nickoe -- If you know Python, there is a lot of room for helping to improve the python API for querying the PDK too...
<nickoe> To be honest, I probably don't have time to do much useful, but I am still interested in investigating it at least
<nickoe> I didn't know about that project. I am not even familiar with litex.
m_w has quit [Ping timeout: 246 seconds]