| *** tpb has joined #symbiflow | 00:00 | |
| *** OmniMancer1 has joined #symbiflow | 01:38 | |
| *** OmniMancer has quit IRC | 01:40 | |
| *** Degi has quit IRC | 02:29 | |
| *** Degi has joined #symbiflow | 02:30 | |
| *** az0re has joined #symbiflow | 02:49 | |
| *** citypw has joined #symbiflow | 03:02 | |
| *** analognoise1 has joined #symbiflow | 04:08 | |
| *** analognoise has quit IRC | 04:12 | |
| *** kgugala has quit IRC | 04:40 | |
| *** kgugala has joined #symbiflow | 04:41 | |
| *** kgugala_ has joined #symbiflow | 05:00 | |
| *** kgugala has quit IRC | 05:04 | |
| *** _whitelogger has quit IRC | 05:30 | |
| *** _whitelogger has joined #symbiflow | 05:32 | |
| *** epony has quit IRC | 05:46 | |
| *** citypw has quit IRC | 07:10 | |
| *** kgugala has joined #symbiflow | 07:10 | |
| *** kgugala_ has quit IRC | 07:13 | |
| *** kraiskil has joined #symbiflow | 07:26 | |
| *** epony has joined #symbiflow | 07:29 | |
| *** kraiskil has quit IRC | 08:07 | |
| *** kraiskil has joined #symbiflow | 10:11 | |
| *** kraiskil has quit IRC | 10:24 | |
| *** unrznbl[m] has quit IRC | 11:02 | |
| *** promach3 has quit IRC | 11:02 | |
| *** xobs has quit IRC | 11:02 | |
| *** lopsided98 has quit IRC | 11:06 | |
| *** lopsided98 has joined #symbiflow | 11:09 | |
| *** unrznbl[m] has joined #symbiflow | 11:11 | |
| *** analognoise2 has joined #symbiflow | 11:33 | |
| *** xobs has joined #symbiflow | 11:33 | |
| *** promach3 has joined #symbiflow | 11:33 | |
| *** _whitelogger has quit IRC | 11:34 | |
| *** analognoise1 has quit IRC | 11:34 | |
| *** ktemkin has quit IRC | 11:34 | |
| *** kmehall_ has quit IRC | 11:34 | |
| *** ktemkin has joined #symbiflow | 11:34 | |
| *** _whitelogger has joined #symbiflow | 11:36 | |
| *** kmehall_ has joined #symbiflow | 11:40 | |
| *** citypw has joined #symbiflow | 12:06 | |
| *** citypw has joined #symbiflow | 12:11 | |
| sf-slack | <olof.kindgren> Is this where all the cool kids hang out? | 12:49 |
|---|---|---|
| sf-slack | <kgugala> yep, this is the place | 12:52 |
| sf-slack | <olof.kindgren> ok, I'll leave then | 12:52 |
| sf-slack | <kgugala> we'll miss you | 12: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 chips | 12:58 |
| sf-slack | <kgugala> @mkurc can probably help here | 12:58 |
| sf-slack | <mkurc> Yep, I'm all ears | 12:58 |
| sf-slack | <olof.kindgren> Cool. Thans | 12:59 |
| sf-slack | <olof.kindgren> I'm running SERV through symbiflow with the soon-to-be-merged Edalize backend | 12: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 that | 13:00 |
| sf-slack | <olof.kindgren> Because it doesn't seem to work to constrain the input clock directly | 13: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 wire | 13: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 A3 | 13: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 directly | 13: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 preferred | 13:03 |
| *** shivam has joined #symbiflow | 13:03 | |
| sf-slack | <mkurc> On the board there is a clock source for the whole soc that can go to the FPGA internally | 13: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 FPGA | 13:04 |
| sf-slack | <mkurc> To use SoC clocks you have to instantiate a cell that represents the SoC | 13:05 |
| sf-slack | <mkurc> It has two clock sources | 13: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> Aha | 13: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 remember | 13: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 programmer | 13: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 constrain | 13:08 |
| sf-slack | <mkurc> Yes | 13:08 |
| sf-slack | <olof.kindgren> Is there a list of cells somewhere? | 13:08 |
| sf-slack | <olof.kindgren> I only found RAM and FIFO | 13: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 designs | 13:09 |
| sf-slack | <kgugala> there should also be a list of them in Yosys | 13:09 |
| sf-slack | <mkurc> This is a simple blinky-like example that uses both clocks from the SoC: https://github.com/QuickLogic-Corp/symbiflow-arch-defs/tree/quicklogic-upstream-rebase/quicklogic/pp3/tests/soc_clocks | 13:11 |
| tpb | Title: symbiflow-arch-defs/quicklogic/pp3/tests/soc_clocks at quicklogic-upstream-rebase · QuickLogic-Corp/symbiflow-arch-defs · GitHub (at github.com) | 13:11 |
| 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 | 13:12 |
| tpb | Title: GitHub - fusesoc/blinky: Example LED blinking project for your FPGA dev board of choice (at github.com) | 13:12 |
| sf-slack | <mkurc> sure | 13: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 documentation | 13:15 |
| sf-slack | <olof.kindgren> Ah ok. Where do I find the soc docs? Only managed to find a spreadsheet with register addresses | 13:16 |
| sf-slack | <mkurc> I guess that these are the ones: https://www.quicklogic.com/products/soc/eos-s3-microcontroller/ | 13:17 |
| tpb | Title: EOS S3: MCU + eFPGA SoC with 100% Open Source Development Tools | QuickLogic Corporation (at www.quicklogic.com) | 13:17 |
| 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 hoping | 13: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 there | 13:25 |
| sf-slack | <mkurc> Yes, VPR should be aware that gclkbuff is a clock buffer and should propagate a constraint through it | 13: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 log | 13:27 |
| sf-slack | <olof.kindgren> route.log ? | 13:27 |
| sf-slack | <mkurc> probably too, I'd need to check | 13: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 correct | 13:29 |
| sf-slack | <mkurc> so one PB-LOGIC is a single LOGIC cell of the FPGA | 13:30 |
| sf-slack | <olof.kindgren> Cool, then my guess was right that I should be able to fit three SERV cores in it | 13: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 each | 13:36 |
| sf-slack | <mkurc> Each of them can be used either as a single 2k or 2x1k | 13:37 |
| sf-slack | <olof.kindgren> aha. cool | 13: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 IRC | 15:49 | |
| *** OmniMancer1 has quit IRC | 16:11 | |
| *** ArturSwiderski has joined #symbiflow | 16:27 | |
| 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 | 16:42 |
| 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 | 16:42 |
| 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 | 17:19 |
| *** ArturSwiderski has quit IRC | 17:20 | |
| *** shivam has quit IRC | 17:53 | |
| *** umarcor has joined #symbiflow | 18:13 | |
| *** juanmard has joined #symbiflow | 18:23 | |
| *** analognoise2 has quit IRC | 18:48 | |
| *** kraiskil has joined #symbiflow | 18:54 | |
| *** az0re has quit IRC | 19:03 | |
| *** ArturSwiderski has joined #symbiflow | 19:04 | |
| *** ArturSwiderski has quit IRC | 19:04 | |
| *** tcal has joined #symbiflow | 19:11 | |
| *** analognoise has joined #symbiflow | 19:14 | |
| *** az0re has joined #symbiflow | 19: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 FuseSoC | 20: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 routing | 20: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 solution | 20:33 |
| sorear | has anyone considered making it multi-threaded | 20: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 FuseSoC | 20:34 |
| *** ArturSwiderski has joined #symbiflow | 20: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 with | 20:44 |
| sf-slack | <olof.kindgren> Learning one piece at a time definitely sounds like a good idea | 20: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 run | 20:48 |
| *** analognoise has quit IRC | 20:48 | |
| *** ArturSwiderski has quit IRC | 20:55 | |
| Lofty | Hi Olof | 20: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 future | 21: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 Lofty | 21:15 |
| Lofty | Pretty sure I got as much as I could from the 7400 series chips :P | 21: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 FPGA | 21:22 |
| sf-slack | <olof.kindgren> But it could be that there will be too many wires between the modules | 21:22 |
| sf-slack | <olof.kindgren> But that's for another day. There are sheep to be counted right now | 21:23 |
| *** kraiskil has quit IRC | 21:58 | |
| *** kraiskil has joined #symbiflow | 22:03 | |
| *** maartenBE has quit IRC | 22:19 | |
| *** maartenBE has joined #symbiflow | 22:20 | |
| -_whitenotifier-f- [symbiflow-xc-fasm2bels] jgoeders opened issue #29: assert - no upstream connection - https://git.io/JTfOD | 22:45 | |
| *** FFY00 has quit IRC | 23:25 | |
| *** FFY00 has joined #symbiflow | 23:25 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!