Friday, 2020-10-09

*** tpb has joined #symbiflow00:00
*** OmniMancer1 has joined #symbiflow01:38
*** OmniMancer has quit IRC01:40
*** Degi has quit IRC02:29
*** Degi has joined #symbiflow02:30
*** az0re has joined #symbiflow02:49
*** citypw has joined #symbiflow03:02
*** analognoise1 has joined #symbiflow04:08
*** analognoise has quit IRC04:12
*** kgugala has quit IRC04:40
*** kgugala has joined #symbiflow04:41
*** kgugala_ has joined #symbiflow05:00
*** kgugala has quit IRC05:04
*** _whitelogger has quit IRC05:30
*** _whitelogger has joined #symbiflow05:32
*** epony has quit IRC05:46
*** citypw has quit IRC07:10
*** kgugala has joined #symbiflow07:10
*** kgugala_ has quit IRC07:13
*** kraiskil has joined #symbiflow07:26
*** epony has joined #symbiflow07:29
*** kraiskil has quit IRC08:07
*** kraiskil has joined #symbiflow10:11
*** kraiskil has quit IRC10:24
*** unrznbl[m] has quit IRC11:02
*** promach3 has quit IRC11:02
*** xobs has quit IRC11:02
*** lopsided98 has quit IRC11:06
*** lopsided98 has joined #symbiflow11:09
*** unrznbl[m] has joined #symbiflow11:11
*** analognoise2 has joined #symbiflow11:33
*** xobs has joined #symbiflow11:33
*** promach3 has joined #symbiflow11:33
*** _whitelogger has quit IRC11:34
*** analognoise1 has quit IRC11:34
*** ktemkin has quit IRC11:34
*** kmehall_ has quit IRC11:34
*** ktemkin has joined #symbiflow11:34
*** _whitelogger has joined #symbiflow11:36
*** kmehall_ has joined #symbiflow11:40
*** citypw has joined #symbiflow12:06
*** citypw has joined #symbiflow12:11
sf-slack<olof.kindgren> Is this where all the cool kids hang out?12:49
sf-slack<kgugala> yep, this is the place12:52
sf-slack<olof.kindgren> ok, I'll leave then12:52
sf-slack<kgugala> we'll miss you12:54
sf-slack<olof.kindgren> You're supposed to tell me I can stay :)12:57
sf-slack<olof.kindgren> Anyway, I have some questions around clocks and timing for the Quicklogic chips12:58
sf-slack<kgugala> @mkurc can probably help here12:58
sf-slack<mkurc> Yep, I'm all ears12:58
sf-slack<olof.kindgren> Cool. Thans12:59
sf-slack<olof.kindgren> I'm running SERV through symbiflow with the soon-to-be-merged Edalize backend12:59
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 that13:00
sf-slack<olof.kindgren> Because it doesn't seem to work to constrain the input clock directly13:00
sf-slack<mkurc> Are you using internal clocks from the SoC or an external clock input?13:01
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 wire13:01
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)13:01
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 A313:02
sf-slack<mkurc> I need to check the schematic but I doubt that there is a dedicated crystal gen. that goes to the FPGA directly13:03
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 preferred13:03
*** shivam has joined #symbiflow13:03
sf-slack<mkurc> On the board there is a clock source for the whole soc that can go to the FPGA internally13:03
sf-slack<olof.kindgren> ah ok. Do I need to instantiate a primitive to use that clock, or how do I do  it?13:04
sf-slack<mkurc> Yes, let me explain:13:04
sf-slack<mkurc> You can use either clocks provided by the SoC or introduced directly to the FPGA13:04
sf-slack<mkurc> To use SoC clocks you have to instantiate a cell that represents the SoC13:05
sf-slack<mkurc> It has two clock sources13:05
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.13:06
sf-slack<olof.kindgren> Aha13:07
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?13:07
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)13:07
sf-slack<mkurc> By default you get 12MHz as far as I remember13:08
sf-slack<mkurc> To change that you need to write some regs on the system bus. That can be done also via a JTAG programmer13:08
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 constrain13:08
sf-slack<mkurc> Yes13:08
sf-slack<olof.kindgren> Is there a list of cells somewhere?13:08
sf-slack<olof.kindgren> I only found RAM and FIFO13:08
sf-slack<mkurc> So you instantiate the "SoC" cell and the global clock buffer.13:08
sf-slack<mkurc> You may refer to some example designs13:09
sf-slack<kgugala> there should also be a list of them in Yosys13:09
sf-slack<mkurc> This is a simple blinky-like example that uses both clocks from the SoC:
tpbTitle: symbiflow-arch-defs/quicklogic/pp3/tests/soc_clocks at quicklogic-upstream-rebase · QuickLogic-Corp/symbiflow-arch-defs · GitHub (at
sf-slack<olof.kindgren> Cool. Speaking of blinky, don't forget to add Quickfeather support to project LED to Believe :)
tpbTitle: GitHub - fusesoc/blinky: Example LED blinking project for your FPGA dev board of choice (at
sf-slack<mkurc> sure13:13
sf-slack<olof.kindgren> So, are both clocks in that example 12MHz and running by default?13:14
sf-slack<mkurc> I'm not 100% sure if its 12MHz. That should be checked against the SoC documentation13:15
sf-slack<olof.kindgren> Ah ok. Where do I find the soc docs? Only managed to find a spreadsheet with register addresses13:16
sf-slack<mkurc> I guess that these are the ones:
tpbTitle: EOS S3: MCU + eFPGA SoC with 100% Open Source Development Tools | QuickLogic Corporation (at
sf-slack<mkurc> "S3 Technical Reference Manual"13:17
sf-slack<olof.kindgren> Thanks! That seems to contain a lot of things I have or will be asking about :)13:19
sf-slack<mkurc> No problem :)13:21
sf-slack<olof.kindgren> Hmm.. it doesn't seem to find the clock net to constrain as I was hoping13:22
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 there13:25
sf-slack<mkurc> Yes, VPR should be aware that gclkbuff is a clock buffer and should propagate a constraint through it13:25
sf-slack<olof.kindgren> Which file would be best to look at the final resource usage of the design?13:26
sf-slack<mkurc> It should be either packing or placement log13:27
sf-slack<olof.kindgren> route.log ?13:27
sf-slack<mkurc> probably too, I'd need to check13:27
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?13:29
sf-slack<olof.kindgren> I think I saw there were 891 of them somewhere. Does this sound correct?13:29
sf-slack<mkurc> Yes it is correct13:29
sf-slack<mkurc> so one PB-LOGIC is a single LOGIC cell of the FPGA13:30
sf-slack<olof.kindgren> Cool, then my guess was right that I should be able to fit three SERV cores in it13:30
sf-slack<mkurc> Nice!13:30
sf-slack<olof.kindgren> Are the FPGA SRAMs 2kB each?13:34
sf-slack<mkurc> Yes, there are 4 RAMs, 2kB each13:36
sf-slack<mkurc> Each of them can be used either as a single 2k or 2x1k13:37
sf-slack<olof.kindgren> aha. cool13:55
sf-slack<olof.kindgren> And is `package : PD64` correct for the chip on the quickfeather?13:56
sf-slack<mkurc> Its `PU64`13:59
*** citypw has quit IRC15:49
*** OmniMancer1 has quit IRC16:11
*** ArturSwiderski has joined #symbiflow16:27
ArturSwiderskiHi, 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 any16:42
ArturSwiderskiwork. 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++ tasks16:42
ArturSwiderskiok I have sent an email with more or less the same content. I will look for response to my request in my mailbox17:19
*** ArturSwiderski has quit IRC17:20
*** shivam has quit IRC17:53
*** umarcor has joined #symbiflow18:13
*** juanmard has joined #symbiflow18:23
*** analognoise2 has quit IRC18:48
*** kraiskil has joined #symbiflow18:54
*** az0re has quit IRC19:03
*** ArturSwiderski has joined #symbiflow19:04
*** ArturSwiderski has quit IRC19:04
*** tcal has joined #symbiflow19:11
*** analognoise has joined #symbiflow19:14
*** az0re has joined #symbiflow19:33
mithro@olof.kindgren: You can fit 3 SERV on the EOS-S3 logic!? That seems too many?19:50
sf-slack<olof.kindgren> @kd2cca I just saw your question in the general channel. It sounds like you're looking for FuseSoC20:30
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 routing20:32
sf-slack<olof.kindgren> As @kgugala concluded today, it's not the fastest CPU, but at least it's small :)20:33
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 solution20:33
sorearhas anyone considered making it multi-threaded20:34
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 FuseSoC20:34
*** ArturSwiderski has joined #symbiflow20:39
sf-slack<kd2cca> FuseSOC is likely what we want in the long term. We pretty much have a structure that would support it.20:43
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 with20:44
sf-slack<olof.kindgren> Learning one piece at a time definitely sounds like a good idea20:46
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 run20:48
*** analognoise has quit IRC20:48
*** ArturSwiderski has quit IRC20:55
LoftyHi Olof20:58
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 future21:03
sf-slack<olof.kindgren> Well, if you need to target different simulators when developing your peripherals, FuseSoC is your friend there too ;)21:14
sf-slack<olof.kindgren> Hi Lofty21:15
LoftyPretty sure I got as much as I could from the 7400 series chips :P21:15
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 FPGA21:22
sf-slack<olof.kindgren> But it could be that there will be too many wires between the modules21:22
sf-slack<olof.kindgren> But that's for another day. There are sheep to be counted right now21:23
*** kraiskil has quit IRC21:58
*** kraiskil has joined #symbiflow22:03
*** maartenBE has quit IRC22:19
*** maartenBE has joined #symbiflow22:20
-_whitenotifier-f- [symbiflow-xc-fasm2bels] jgoeders opened issue #29: assert - no upstream connection -
*** FFY00 has quit IRC23:25
*** FFY00 has joined #symbiflow23:25

Generated by 2.17.2 by Marius Gedminas - find it at!