| *** tpb has joined #yosys | 00:00 | |
| *** bzztploink has joined #yosys | 00:13 | |
| *** az0re has joined #yosys | 01:05 | |
| *** rlee287 has quit IRC | 01:57 | |
| *** BinaryLust has quit IRC | 02:36 | |
| *** BinaryLust has joined #yosys | 02:37 | |
| *** Degi has quit IRC | 03:20 | |
| *** Degi has joined #yosys | 03:22 | |
| *** _whitelogger has quit IRC | 04:21 | |
| *** _whitelogger has joined #yosys | 04:23 | |
| *** bzztploink has quit IRC | 06:07 | |
| *** bzztploink has joined #yosys | 06:17 | |
| *** _whitelogger has quit IRC | 06:27 | |
| *** _whitelogger has joined #yosys | 06:29 | |
| *** dys has quit IRC | 06:34 | |
| *** citypw has joined #yosys | 06:42 | |
| *** benh has joined #yosys | 07:26 | |
| benh | Somebody familiar with ghdl-synth + yosys around ? | 07:27 |
|---|---|---|
| benh | I've been trying to use them to convert the microwatt cpu to verilog to be able to sim it in LiteX (I am one of microwatt devs) | 07:27 |
| benh | and have hit a couple of issues... | 07:27 |
| benh | the main one is debugging is really hard due to how vhdl records are turned into very large verilog vectors (arrays ?) that encompass all the bits of all the elements in the record | 07:29 |
| benh | I was hoping it would be possible to improve this by instead breaking them up into separate objects prefixed by record name ? | 07:29 |
| benh | microwatt uses a lot of records.... | 07:29 |
| benh | but I'm not sure if this happens in ghdl, the ghdl-yosys plugin or yosys itself, and thus where to report the feature request :) | 07:29 |
| *** az0re has quit IRC | 07:31 | |
| daveshah | What happens to records in the ghdl simplified VHDL mode? | 07:43 |
| daveshah | The solution for this is might be to add aliases for the record elements | 07:43 |
| daveshah | Splitting up entirely might be more complex due to how ghdl works, I don't know | 07:44 |
| benh | daveshah: they seem to still be around in the simplified vhdl | 07:57 |
| daveshah | I guess they are split up in the plugin then | 07:57 |
| benh | yeah possibly, I'll put an issue on github on the plugin, we'll see what Tristan says | 07:59 |
| benh | another thing I noticed is when trying to sim in litex the result of the verilog conversion I get a buckload of warnings | 07:59 |
| benh | about case statements with overlapping cases | 07:59 |
| benh | it looks like a bunch of tests against things like "00000001", "00000010" etc... are turned into "???????1", "??????1?" etc... on the verilog side, whihc looks ... odd | 07:59 |
| daveshah | Those probably come from Yosys $pmux cells | 08:00 |
| benh | not sure if it's something I should worry about, I haven't completely managed to match that back to the original vhdl | 08:00 |
| benh | .. yet | 08:00 |
| daveshah | If ghdl is creating those cells correctly then the select inputs should be one hot | 08:00 |
| benh | ok, makes sense | 08:00 |
| benh | thanks | 08:01 |
| *** Asu has joined #yosys | 08:04 | |
| *** BinaryLust has quit IRC | 08:16 | |
| *** Asu has quit IRC | 09:14 | |
| *** Asu has joined #yosys | 09:15 | |
| tnt | Does yosys have a concept of attribute on nets or ports or just on cells ? (internally I mean) | 09:32 |
| whitequark | yosys has attributes on nets | 09:32 |
| whitequark | attributes on ports are a bit weird | 09:32 |
| tnt | yeah, nets it better for me anyway. | 09:33 |
| *** N2TOH has quit IRC | 13:16 | |
| *** citypw has quit IRC | 15:32 | |
| somlo | daveshah: ping | 15:33 |
| daveshah | somlo: pong | 15:33 |
| somlo | daveshah: I'm trying to refresh my fedora packages of prjtrellis, and I just noticed the database commit linked from prjtrellis isn't `master` on prjtrellis-db | 15:34 |
| daveshah | Oh, maybe I forgot to actually merge a PR | 15:34 |
| daveshah | easy enough to fix | 15:34 |
| somlo | any relevant back-story that would impact packaging in any way ? | 15:34 |
| somlo | oh, ok, a "clerical" problem :) | 15:35 |
| daveshah | should be fixed now, tx for spotting | 15:36 |
| somlo | awesome, thanks! | 15:36 |
| *** emeb has joined #yosys | 15:37 | |
| *** BinaryLust has joined #yosys | 15:43 | |
| *** vidbina has joined #yosys | 15:59 | |
| *** rrika_ is now known as rrika | 16:36 | |
| *** ross_s has joined #yosys | 17:09 | |
| ross_s | Anyone had problems using the qspi mode on ecppack? After it reads the qspi mode from the bitstream (0x79 0x59) I see what looks like a minor clock skip on the fpga, then the two commands 0xE9 and 0x80 which don't appear to be valid spi flash commands according to the W25Q128 datasheet | 17:18 |
| daveshah | It is supposed to use 0xEB for quad SPI reads not 0xE9 | 17:26 |
| daveshah | according to FPGA-TN-02039-1.7 | 17:26 |
| ross_s | interesting, it looks like ECPPack uses these values: https://github.com/SymbiFlow/prjtrellis/blob/master/libtrellis/src/Bitstream.cpp#L27-L30 | 17:28 |
| tpb | Title: prjtrellis/Bitstream.cpp at master · SymbiFlow/prjtrellis · GitHub (at github.com) | 17:28 |
| daveshah | Those are mode values | 17:28 |
| ross_s | ah sorry, misread your comment | 17:28 |
| daveshah | I was referring to the commands that the FPGA generates | 17:28 |
| ross_s | Here's a shot of the logic analyzer on the spi https://public.rhye.org/ecp_qspi.png | 17:30 |
| ross_s | it could be that it's getting confused by the missed clock cycle | 17:30 |
| tnt | Huh ... chip select should be released between command anyway. | 17:32 |
| ZipCPU | Without releasing the chip select, this isn't a new command at all | 17:32 |
| ross_s | yeah that also seemed suspect, I thought it might be a digitization glitch but the analog trace also seems low | 17:32 |
| ross_s | this device does boot fine in normal spi mode, so I don't _think_ there is anything electrically wrong with the ~CS line | 17:33 |
| *** rlee287 has joined #yosys | 17:33 | |
| tnt | And it's definitly EB | 17:33 |
| ZipCPU | I'd figure out what's going on with CS before even wondering if the xe9 should an xeb or not | 17:34 |
| tnt | I can see it on the trace ... | 17:34 |
| ross_s | looks like there's a very small spurious clock on the analyzer, your right tnt | 17:34 |
| ZipCPU | As for the discontinuous clock ... that's per spec. You're allowed to stop the clock | 17:34 |
| tnt | But your LA seems to read clock glitches, probably a signal integrity issue when probing. | 17:34 |
| daveshah | What board is this? | 17:35 |
| ross_s | one I designed to learn more about ECP5, I'm afraid I haven't published any design files yet | 17:36 |
| daveshah | What signal is CS connected to? | 17:36 |
| tnt | but as ZipCPU said without CS it doesn't matter anyway. | 17:36 |
| daveshah | there are a few signals that probably behave enough like CS for a simple single SPI boot to work | 17:36 |
| ross_s | PB15A/HOLDN/DI/BUSY/CSSPIN/CEN, ball N8 on the 256-pin BGA | 17:37 |
| daveshah | That's fine | 17:37 |
| tnt | need a pull up ? | 17:38 |
| daveshah | Config guide says it needs a 4.7k pullup | 17:38 |
| ross_s | I have 10k pullups on CS, SCK, D2 and D3 | 17:38 |
| daveshah | I doubt 10k vs 4.7k would make enough of a difference to see no pulse | 17:38 |
| daveshah | so that sounds fine | 17:38 |
| tnt | shorted then ? | 17:38 |
| daveshah | Seems most likely | 17:39 |
| ross_s | https://public.rhye.org/ecp_start.png | 17:39 |
| daveshah | Because the main bitstream read is the first command sent, I guess basic reads would still start | 17:39 |
| ross_s | seems to behave normally when it first starts | 17:39 |
| daveshah | Hmm | 17:40 |
| daveshah | Just checked and the hadbadge project uses qspi mode so it should work fine | 17:40 |
| ZipCPU | x3 would be the standard SPI read command | 17:41 |
| ross_s | yeah, it looks like it starts with the normal SPI read, then gets to the speed/mode settings and changes over | 17:41 |
| daveshah | Yeah, the startup looks fine | 17:41 |
| ZipCPU | Where does CS toggle again? If the CS signal never deactivates, the design will stay in SPI mode | 17:43 |
| ross_s | As in where does it toggle on this board? It doesn't seem to mid-stream, only at the beginning of the read. Currently paging through TN1260 to find a timing diagram for expected behaviour | 17:45 |
| daveshah | I don't think there is one | 17:46 |
| daveshah | but note that FPGA-TN-02039 is a replacement to TN1260 and has a bit more detail in a couple of other places | 17:46 |
| *** vidbina has quit IRC | 17:47 | |
| daveshah | It's another long shot but a _higher_ clock frequency might be worth trying (I don't know why it would change things but afaik qspi mode has only been tested at higher frequencies before) | 17:49 |
| ross_s | I can give it a test | 17:49 |
| ross_s | hmm appears the same | 17:52 |
| ross_s | it looks like it only runs at the 2.4MHz clock for that section of the bitstream anyway | 17:52 |
| ross_s | a 1x spi read mode at 62MHz does work, but then there's no need to toggle CS there, it just ups the clock and keeps going | 17:53 |
| daveshah | Might as well be worth checking fast read or dual SPI modes which would also involve a toggle | 17:57 |
| ross_s | ok interesting, if I don't pass --spimode to ecppack I get a bitstream that works, at any freq. If I do specify fast-read, then it hangs | 18:00 |
| daveshah | fast-read should be switching to 0x0B | 18:01 |
| ross_s | once again, with fast-read it sends 0x0b (though the logic analyzer reads 0x09, there is again a glitch specifically on that byte) but doesn't toggle ~CS | 18:02 |
| *** cr1901_modern has quit IRC | 18:12 | |
| *** cr1901_modern has joined #yosys | 18:18 | |
| *** BinaryLust has quit IRC | 18:35 | |
| *** gmc has joined #yosys | 19:55 | |
| *** Asuu has joined #yosys | 20:59 | |
| *** Asu has quit IRC | 21:00 | |
| *** BinaryLust has joined #yosys | 21:18 | |
| *** rlee287 has quit IRC | 21:24 | |
| *** N2TOH has joined #yosys | 22:00 | |
| *** rlee287 has joined #yosys | 22:08 | |
| *** Asu has joined #yosys | 22:09 | |
| *** Asuu has quit IRC | 22:09 | |
| *** rlee287 has quit IRC | 22:09 | |
| *** BinaryLust has quit IRC | 22:15 | |
| *** Asu has quit IRC | 23:09 | |
| *** proteusguy has quit IRC | 23:22 | |
| *** proteusguy has joined #yosys | 23:35 | |
| *** BinaryLust has joined #yosys | 23:42 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
