kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 258 seconds]
_whitelogger has joined #symbiflow
epony has quit [Remote host closed the connection]
citypw has quit [Ping timeout: 240 seconds]
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 272 seconds]
kraiskil has joined #symbiflow
epony has joined #symbiflow
kraiskil has quit [Ping timeout: 260 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 265 seconds]
unrznbl[m] has quit [Quit: killed]
promach3 has quit [Quit: killed]
xobs has quit [Quit: killed]
lopsided98 has quit [Ping timeout: 260 seconds]
lopsided98 has joined #symbiflow
unrznbl[m] has joined #symbiflow
_whitelogger has joined #symbiflow
kmehall_ has joined #symbiflow
citypw has joined #symbiflow
citypw has quit [Remote host closed the connection]
citypw has joined #symbiflow
<sf-slack>
<olof.kindgren> Is this where all the cool kids hang out?
<sf-slack>
<kgugala> yep, this is the place
<sf-slack>
<olof.kindgren> ok, I'll leave then
<sf-slack>
<kgugala> we'll miss you
<sf-slack>
<olof.kindgren> You're supposed to tell me I can stay :)
<sf-slack>
<olof.kindgren> Anyway, I have some questions around clocks and timing for the Quicklogic chips
<sf-slack>
<kgugala> @mkurc can probably help here
<sf-slack>
<mkurc> Yep, I'm all ears
<sf-slack>
<olof.kindgren> Cool. Thans
<sf-slack>
<olof.kindgren> I'm running SERV through symbiflow with the soon-to-be-merged Edalize backend
<sf-slack>
<olof.kindgren> But I haven't figured out a good way to constrain the clocks. I guess symbiflow creates an implcit clock buffer and that VPR doesn't follow timing through that
<sf-slack>
<olof.kindgren> Because it doesn't seem to work to constrain the input clock directly
<sf-slack>
<mkurc> Are you using internal clocks from the SoC or an external clock input?
<sf-slack>
<olof.kindgren> And that's ok as long as I can constrain the output clock from the buffer (if there is a buffer). The normal way I would do that is to instantiate a clock buffer manually so that I have control of the output wire
<sf-slack>
<olof.kindgren> @mkurc That's a very good question. I don't know. I haven't got a chip yet (it's on its way)
<sf-slack>
<olof.kindgren> So, what are my clocking possibilities on the quick feather? I found some pcf/sdc somewhere that made me think there is a 83MHz clock connected to pin A3
<sf-slack>
<mkurc> I need to check the schematic but I doubt that there is a dedicated crystal gen. that goes to the FPGA directly
<sf-slack>
<olof.kindgren> I'm fine to use whatever clock that exists. It seems though like SERV will only run at 20MHz on this chip, so a 16MHz clock would be preferred
shivam has joined #symbiflow
<sf-slack>
<mkurc> On the board there is a clock source for the whole soc that can go to the FPGA internally
<sf-slack>
<olof.kindgren> ah ok. Do I need to instantiate a primitive to use that clock, or how do I do it?
<sf-slack>
<mkurc> Yes, let me explain:
<sf-slack>
<mkurc> You can use either clocks provided by the SoC or introduced directly to the FPGA
<sf-slack>
<mkurc> To use SoC clocks you have to instantiate a cell that represents the SoC
<sf-slack>
<mkurc> It has two clock sources
<sf-slack>
<mkurc> And the thing is that these sources physically do not connect directly to the clock network of the FPGA, they have to be routed first through regular rr resources to a global clock buffer.
<sf-slack>
<olof.kindgren> Aha
<sf-slack>
<olof.kindgren> Do I need to set up the clocks on the ARM side as well, or are they configurable through the bitstream?
<sf-slack>
<mkurc> By default VPR doesn't consider the net before the global clock buffer as a clock (probably it is something that could be improved)
<sf-slack>
<mkurc> By default you get 12MHz as far as I remember
<sf-slack>
<mkurc> To change that you need to write some regs on the system bus. That can be done also via a JTAG programmer
<sf-slack>
<olof.kindgren> That's fine, but then I would like to instantiate a global buffer manually so that I know which wire name to constrain
<sf-slack>
<mkurc> Yes
<sf-slack>
<olof.kindgren> Is there a list of cells somewhere?
<sf-slack>
<olof.kindgren> I only found RAM and FIFO
<sf-slack>
<mkurc> So you instantiate the "SoC" cell and the global clock buffer.
<sf-slack>
<mkurc> You may refer to some example designs
<sf-slack>
<kgugala> there should also be a list of them in Yosys
<sf-slack>
<olof.kindgren> Cool. Speaking of blinky, don't forget to add Quickfeather support to project LED to Believe :) https://github.com/fusesoc/blinky
<tpb>
Title: GitHub - fusesoc/blinky: Example LED blinking project for your FPGA dev board of choice (at github.com)
<sf-slack>
<mkurc> sure
<sf-slack>
<olof.kindgren> So, are both clocks in that example 12MHz and running by default?
<sf-slack>
<mkurc> I'm not 100% sure if its 12MHz. That should be checked against the SoC documentation
<sf-slack>
<olof.kindgren> Ah ok. Where do I find the soc docs? Only managed to find a spreadsheet with register addresses
<sf-slack>
<olof.kindgren> Thanks! That seems to contain a lot of things I have or will be asking about :)
<sf-slack>
<mkurc> No problem :)
<sf-slack>
<olof.kindgren> Hmm.. it doesn't seem to find the clock net to constrain as I was hoping
<sf-slack>
<olof.kindgren> ok, it managed to match the name of the wire going into the gclkbuff at least, and it seems to have followed it through there
<sf-slack>
<mkurc> Yes, VPR should be aware that gclkbuff is a clock buffer and should propagate a constraint through it
<sf-slack>
<olof.kindgren> Which file would be best to look at the final resource usage of the design?
<sf-slack>
<mkurc> It should be either packing or placement log
<sf-slack>
<olof.kindgren> route.log ?
<sf-slack>
<mkurc> probably too, I'd need to check
<sf-slack>
<olof.kindgren> ```Placement resource usage: PB-ASSP implemented as TL-ASSP : 1 PB-RAM implemented as TL-RAM : 1 PB-BIDIR implemented as TL-BIDIR : 1 PB-GMUX implemented as TL-GMUX : 2 PB-SYN_VCC implemented as TL-SYN_VCC: 1 PB-SYN_GND implemented as TL-SYN_GND: 1 PB-LOGIC implemented as TL-LOGIC : 256``` So, does this basically say I'm using 256 logic elements, LUTs, whatever QL calls them?
<sf-slack>
<olof.kindgren> I think I saw there were 891 of them somewhere. Does this sound correct?
<sf-slack>
<mkurc> Yes it is correct
<sf-slack>
<mkurc> so one PB-LOGIC is a single LOGIC cell of the FPGA
<sf-slack>
<olof.kindgren> Cool, then my guess was right that I should be able to fit three SERV cores in it
<sf-slack>
<mkurc> Nice!
<sf-slack>
<olof.kindgren> Are the FPGA SRAMs 2kB each?
<sf-slack>
<mkurc> Yes, there are 4 RAMs, 2kB each
<sf-slack>
<mkurc> Each of them can be used either as a single 2k or 2x1k
<sf-slack>
<olof.kindgren> aha. cool
<sf-slack>
<olof.kindgren> And is `package : PD64` correct for the chip on the quickfeather?
<sf-slack>
<mkurc> Its `PU64`
citypw has quit [Ping timeout: 240 seconds]
OmniMancer1 has quit [Quit: Leaving.]
ArturSwiderski has joined #symbiflow
<ArturSwiderski>
Hi, I am looking for a job, but nowadays it may take a long time because companies at least in my country prefer to stay lean for a time being. In general I have finished my current tasks and projects. I have nothing to do at hand, so I decided to look for some work in an open source space, to make something useful, before I will find any
<ArturSwiderski>
work. I am here not by accident I like FPGA as an hobbyist I know a bit of VHDL,so Verilog should be within my reach, but in general I am c++ programmer/bug fixer. I am looking for either Verilog or C++ tasks
<ArturSwiderski>
ok I have sent an email with more or less the same content. I will look for response to my request in my mailbox
ArturSwiderski has quit [Remote host closed the connection]
shivam has quit [Quit: Connection closed for inactivity]
umarcor has joined #symbiflow
juanmard has joined #symbiflow
analognoise2 has quit [Ping timeout: 244 seconds]
kraiskil has joined #symbiflow
az0re has quit [Remote host closed the connection]
ArturSwiderski has joined #symbiflow
ArturSwiderski has quit [Remote host closed the connection]
tcal has joined #symbiflow
analognoise has joined #symbiflow
az0re has joined #symbiflow
<mithro>
@olof.kindgren: You can fit 3 SERV on the EOS-S3 logic!? That seems too many?
<sf-slack>
<olof.kindgren> @kd2cca I just saw your question in the general channel. It sounds like you're looking for FuseSoC
<sf-slack>
<olof.kindgren> @mithro I haven't tested it yet, but I think it sounds about right. One core used 256 logic cells, so it should fit three with some extra routing
<sf-slack>
<olof.kindgren> As @kgugala concluded today, it's not the fastest CPU, but at least it's small :)
<sf-slack>
<kd2cca> Well you are the dev right? I have look at it quite a bit, but I have since settled on a Makefile solution
<sorear>
has anyone considered making it multi-threaded
<sf-slack>
<olof.kindgren> @kd2cca Yes, I'm the main author of FuseSoC. Making it easier to port designs for different targets is one of the main goals behind FuseSoC
ArturSwiderski has joined #symbiflow
<sf-slack>
<kd2cca> FuseSOC is likely what we want in the long term. We pretty much have a structure that would support it.
<sf-slack>
<kd2cca> Though I am quite the newbie to FPGA stuff, so it is a little easier for me to do the process in Make. A little less cognitive overhead, one less layer of abstraction to deal with
<sf-slack>
<olof.kindgren> Learning one piece at a time definitely sounds like a good idea
<sf-slack>
<olof.kindgren> One thing worth mentioning is that the first thing FuseSoC does is actually creating a Makefile (and other tool scripts), and you can let it stop there before calling any tools. That way you can basically check how the tools are supposed to be run
analognoise has quit [Read error: Connection reset by peer]
ArturSwiderski has quit [Remote host closed the connection]
<Lofty>
Hi Olof
<sf-slack>
<kd2cca> Ah good to know. I will have to try it soon. Right now we are just focused on a peripheral design, but will likely add a RISC-V in the near future
<sf-slack>
<olof.kindgren> Well, if you need to target different simulators when developing your peripherals, FuseSoC is your friend there too ;)
<sf-slack>
<olof.kindgren> Hi Lofty
<Lofty>
Pretty sure I got as much as I could from the 7400 series chips :P
<sf-slack>
<olof.kindgren> It would be really cool if someone wanted to build it. I still wonder if it could actually be doable by splitting it up into several modules, and do one by one while keeping the rest in an FPGA
<sf-slack>
<olof.kindgren> But it could be that there will be too many wires between the modules
<sf-slack>
<olof.kindgren> But that's for another day. There are sheep to be counted right now
kraiskil has quit [Ping timeout: 260 seconds]
kraiskil has joined #symbiflow
maartenBE has quit [Ping timeout: 244 seconds]
maartenBE has joined #symbiflow
<_whitenotifier-f>
[symbiflow-xc-fasm2bels] jgoeders opened issue #29: assert - no upstream connection - https://git.io/JTfOD
FFY00 has quit [Remote host closed the connection]