09:48 <tnt> Mm, in the S3, the RAM have "Selectable pipelined or non-pipelined read data".

09:48 <tnt> But is that an additional data register (so latency=2clk) or is that a switch between async read and synchronous read ?

09:57 <sf-slack> <kgugala> tnt: it adds a flip-flop, so you'll get one additional clk latency when using pipelined

10:03 <tnt> Tx, that's what i would have tought, but I'm having some weird behavior so at this point I'm grasping at straws.

11:02 <tnt> So I need a sanity check ... This is a block diagram of what I'm testing now : https://i.imgur.com/f6DrMF1.png

11:03 <tnt> There is two ram buffers (16 kbits each), configured with assymetric read/write width. One is 32b write / 8b read and the other the opposite. Once side is connected to wishbone for the ARM to access and on the other side is a small copy machine that continuously copy the first 64 bytes from one RAM to the other.

11:03 <tnt> Source: https://github.com/smunaut/qorc-sdk/blob/ram_test/qf_apps/qf_advancedfpga/fpga/rtl/top.v#L129

11:03 <tpb> Title: qorc-sdk/top.v at ram_test · smunaut/qorc-sdk · GitHub (at github.com)

11:04 <tnt> (for debug purposes I only copy the lower nibble of each byte, the upper nibble is replaces with the 4 LSBs of the write address).

11:05 <tnt> From the ARM I write for instance 0x00010203 and when reading from the other RAM (which is actually mapped to the same address since one is read only and the other write only), I expect to read that back (at least for the lower nibble).

11:06 <tnt> But ... https://pastebin.com/2qHbrUG6

11:06 <tpb> Title: 00010203 - 37211002 04050607 - 7b655446 08090a0b - bfa9988a 0c0d0e0f - f3eddc - Pastebin.com (at pastebin.com)

11:06 <tnt> this is what I get. (first column is what I write, second column is what I read back).

11:06 <tnt> The upper nibble actually properly reflect the LSB of the address ... the lower niblle are all scrambled over the place.

11:19 <sf-slack> <kgugala> tnt: what accesses do you do in the ARM CPU? byte/word/double word? I see you do not handle the wb_wstb signal (byte select)

11:19 <tnt> kgugala: It should all be double word access.

11:20 <tnt> Let me check the disassembly to make sure gcc did what I wanted.

11:21 <tnt> https://github.com/smunaut/qorc-sdk/blob/ram_test/qf_apps/qf_advancedfpga/src/main.c#L70

11:21 <tpb> Title: qorc-sdk/main.c at ram_test · smunaut/qorc-sdk · GitHub (at github.com)

11:21 <tnt> That's the test code btw.

11:26 <tnt> yeah, all access are 32b. Of course assuming the AHB->WB bridge doesn't split them up but that would be very inconvenient if it did ...

11:52 <tnt> This is driving me nuts, I've been banging my head against it all morning :/

12:43 <tnt> Mmm ... I'm starting to wonder if that's not a hold time viiolation due to (1) high skew because of the global clock buffer getting stripped out and (2) lack of timing data for RAM.

12:50 <sf-slack> <kgugala> Timing data has been merged

12:51 <tnt> kgugala: What repo / branches should I be looking in ?

12:52 <sf-slack> <kgugala> It's here https://github.com/QuickLogic-Corp/symbiflow-arch-defs/tree/quicklogic-upstream-rebase

12:52 <tpb> Title: GitHub - QuickLogic-Corp/symbiflow-arch-defs at quicklogic-upstream-rebase (at github.com)

12:53 <tnt> tx.

13:44 <tnt> kgugala: Nice to see that the place/route/ql_symbiflow/... scripts install has been fixed as well :)

13:45 <tnt> 'route' conflicts with the linux IP routing table manipulation util though :p

13:45 <sf-slack> <kgugala> yep, need to rename it to sth like symbiflow_route or vpr_route

13:50 <tnt> I guess not all ports have timing info ? I still have a lot of stuff like "Warning 1131: Model 'RAM_CE1_FE0_PR1_WSA2_WSB2_VPR' input port 'CLK2EN_0' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input)"

13:50 <tnt> (but not for Read/Write Address/Data port as well)

13:51 <sf-slack> <kgugala> there is no timing info for those in the https://github.com/QuickLogic-Corp/EOS-S3 so import script cannot get them

13:51 <tpb> Title: GitHub - QuickLogic-Corp/EOS-S3: QuickLogic EOS S3 FPGA device description (at github.com)

13:51 <sf-slack> <kgugala> fortunately those inputs are suppose to be constants (at least for now)

13:52 <sf-slack> <kgugala> I mean those are suppose to be routed to constants generators

13:52 <tnt> Most of them seem not that dynamic. CSx_y / CLKxEN_y maybe not.

13:52 <tnt> Any idea what LS / SD / DS are btw ?

13:53 <tnt> Ah, my test seems to behave much better now ! Nice.

13:53 <sf-slack> <kgugala> great

13:56 <sf-slack> <kgugala> AFAIK those LS/SD/DS pins are for power control

13:58 <tnt> Oh yeah "Deep Sleep" "Shut Down"

13:59 <tnt> and ... Light Speed (for overclocking I'm sure :p)

13:59 <sf-slack> <kgugala> :)

14:38 <tnt> I'm trying to use the usb pins (14,10,15) and I just get a place error as soon as I try to do anything with it ... (I randomly assigned a signal to it) https://pastebin.com/BDjXmJgH

14:38 <tpb> Title: cd build && place_vpr -e top.eblif -d ql-eos-s3_wlcsp -p /home/tnt/projects/fpga - Pastebin.com (at pastebin.com)

14:41 <sf-slack> <kgugala> Do you have a pcf published somewhere?

14:42 <sf-slack> <kgugala> Currently I'm travelling, but I can take a look on that later

14:43 <tnt> It's https://github.com/smunaut/qorc-sdk/blob/ram_test/qf_apps/qf_advancedfpga/fpga/rtl/quickfeather.pcf

14:43 <tpb> Title: qorc-sdk/quickfeather.pcf at ram_test · smunaut/qorc-sdk · GitHub (at github.com)

14:43 <tnt> but with the usb stuff uncommented.

14:44 <tnt> Even with just usb_dp is I assign it to pin 10 I get that error. If I assign it to pin 37 (random pick), it works.

15:19 <litghost> tnt: Unclear where the rest of error message ended up, but that error is https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/vpr/src/base/read_place.cpp#L254, which is that the type of cluster being placed doesn't match the arch

15:19 <tpb> Title: vtr-verilog-to-routing/read_place.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

15:21 <litghost> tnt: Open an issue with a tarball with the .net, .pcf and top_io.place files

15:21 <andrewb1999> litghost: In vivado is there a way to create a pblock that, for example, includes the INT_L tiles but excludes the bordering INT_R tiles? Or does vivado limit it just to aligning to CLBs, BRAMs, etc?

15:23 <litghost> andrewb1999: So a pblock typically uses sites to delimit it, right?

15:24 <andrewb1999> litghost: Yes you give it a range of sites

15:25 <litghost> andrewb1999: INT_L/R tiles contain TIEOFF sites, that might do the trick, but I've never tried it

15:29 <andrewb1999> litghost: Vivado doesn't seem to like that. Just wondering if it would be possible to do something like that for mixed vivado overlay and vpr region.

15:29 <litghost> andrewb1999: Losing 1 columns of CLB's to maintain the same overlay is doable

15:30 <litghost> andrewb1999: It is also worth noting that if you design the harness using VPR as we had discussed, we have a way to import that into VIvado again, if that is needed

15:36 <ryancj14> Hello, I'm Ryan Johnson. I'm working with Professor Nelson at BYU, studying fpga performance and device representations. I was wondering if I could get an invitation to the symbiflow slack channel as my professor believes it would be a great way to communicate with this group. We have been working hard on applying the symbiflow tools and would love to participate and help with you all as much as possible. Thanks for

15:36 <ryancj14> your help. My email is ryancj14@gmail.com.

15:36 <sf-slack> <mgielda> hi Ryan, this is bridged with Slack

15:36 <sf-slack> <mgielda> so the IRC == Slack

15:36 <sf-slack> <mgielda> kind of

15:37 <Lofty> I think the IRC is the public side of it, while the Slack is a bit more private

15:37 <sf-slack> <mgielda> but if slack is more convenient - https://join.slack.com/t/symbiflow/shared_invite/enQtNTkyMjcyNTkzOTY4LTU0MzhmYWNjOGMyMTkyNjA0MmEyMWM5OWY3ZDg5MWQ3ODlmOWQwZjk2YzBmMDBjMzkzMzNjYjkwYjAxZTMyNjQ

15:38 <ryancj14> Alright thanks!

15:39 <ryancj14> I did notice they are connected. I think slack will be a bit more convenient.

16:27 <tnt> kgugala: There was a bunch of small errors in ql_symbiflow and synth script that resulted in the PCF and PINMAP files not to be considered during the synth and so it was using BIDIR instead of SDIO_MUX

16:28 <tnt> (missing the part / pcf argument to synth, also some places used PU64_pinmap.csv and other pinmap_PU64.csv ...)

16:28 <sf-slack> <kgugala> I suspected sth like that

16:29 <sf-slack> <kgugala> Do you have a fix somewhere?

16:29 <tnt> yup let me make a patch with the few tweaks I had to make.

16:30 <tnt> actuall which one should it use ? pinmap_PU64.csv or PU64_pinmap.csv ?

16:31 <tnt> looks like the scripts all use pinmap_PU64.csv but the make install puts them in PU64_pinmap.csv

16:33 <sf-slack> <kgugala> The suffixed version looks better

16:33 <sf-slack> <kgugala> I'll check the install target

16:34 <tnt> https://pastebin.com/q5QYSzig

16:34 <tpb> Title: [Diff] diff --git a/quicklogic/toolchain_wrappers/ql_symbiflow b/quicklogic/toolchain_w - Pastebin.com (at pastebin.com)

16:34 <tnt> Then it's just that.

16:35 <sf-slack> <kgugala> thanks

16:36 <sf-slack> <kgugala> do you want to open a PR, or should I include this in the install fix?

16:37 <tnt> feel free to just include it.

16:40 <sf-slack> <kgugala> hmm, from what I see the pinmap naming is already fixed

16:40 <sf-slack> <kgugala> I got pinmap_PD64.csv pinmap_PU64.csv pinmap_WR42.csv

16:40 <sf-slack> <kgugala> so only wrapper fix is needed

16:45 <tnt> Oh yeah, my bad, the ${PACKAGE}_pinmap.csv was from the binary distrib ...

18:04 <tnt> Lofty: On a full PNR run the changes brough it from 545 LCs to 457 LCs, so pretty nice :)

18:05 <Lofty> Woo!

18:05 <Lofty> Thanks for the measurements, tnt

18:42 <andrewb1999> litghost: For the top left region of the a50t, does a frame include from the top of the chip up to but excluding the BRKH row, or does it also include the BRKH row?

19:57 <sf-slack> <timo.callahan> Is symbiflow the best place for Renode questions, or is there another IRC channel?

20:05 <sf-slack> <pgielda> Its fine to ask here. Or open an issue. Or send a PM ;)

20:06 <sf-slack> <timo.callahan> @pgielda Thanks! Nothing specific yet, but I plan to dive into it this coming week.

20:12 <tnt> Does VTR have a gui to visualize the result of a PnR run ?

20:22 <andrewb1999> tnt: It does. Haven't used it with symbiflow though.

20:24 <tnt> I tried adding --disp on ... which did nothing.

20:25 <litghost> tnt: Any chance you are running with a version of VTR with the GUI compiled out?

20:26 <tnt> litghost: well the cmake did say "-- VPR Graphics: Enabled" & "-- EZGL: graphics enabled" so ... I think I should be good

20:29 <litghost> tnt: What VPR step are you doing? --place / --route / --analysis?

20:30 <tnt> Oh yeah,nm, I must have been calling it wrong ... I added it to place and it popped up ...

20:31 <tnt> I was hoping for a bit more detailled cell view though :/ (more like nextpnr gui or fpga_editor )

20:31 <litghost> I believe VPR's gui is mostly focus on the interconnect graph, with few details inside of the island

20:32 <litghost> But I don't have much experience