| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** nelgau <[email protected]> has quit IRC (Read error: Connection reset by peer) | 01:02 | |
| *** nelgau <[email protected]> has joined #yosys | 01:02 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Read error: Connection reset by peer) | 01:05 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #yosys | 01:08 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has joined #yosys | 02:38 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 276 seconds) | 03:46 | |
| *** Guest16 <[email protected]> has joined #yosys | 03:46 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has joined #yosys | 03:49 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 252 seconds) | 04:21 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has quit IRC (Ping timeout: 240 seconds) | 04:48 | |
| *** emeb_mac <[email protected]> has quit IRC (Quit: Leaving.) | 06:59 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has joined #yosys | 10:21 | |
| *** FL4SHK <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 11:23 | |
| *** FL4SHK <[email protected]> has joined #yosys | 11:25 | |
| Zaba | when writing a state machine in verilog, it seems common to have code like "if (state == STATE_1) if (condition) next_state <= STATE; ... if (state == STATE_2) <drive signals as appropriate>". But this seems to inevitably introduce a delay of 1 clock between the condition for transitioning into STATE_2 being recognize and the outputs being driven as appropriate for it. Is there some idiomatic way to avoid this delay without, like, copying and pastin | 11:39 |
|---|---|---|
| Zaba | g the code to drive the outputs into multiple states? | 11:39 |
| tnt | Zaba: sorry but that cut snippet is not clear enough (like are those in process ? what's the sensitivity list). Paste a more reasable example on pastebin .... | 12:26 |
| Zaba | Sure. Sorry. For example: https://paste.rs/EFhZk.txt (illustrative purposes only). A simple external memory controller with read_enable and data connected to an imaginary external chip. | 12:40 |
| tpb | Title: Source Code | Rocket Powered Pastebin (at paste.rs) | 12:40 |
| Zaba | In theory I could change it so that read_enable is driven already when read_stobe goes low, and do everything one clock cycle sooner, but in practice it just seems to inevitably make a mess of everything because code needs to be duplicated between the states? | 12:42 |
| tnt | So you can either have a always @(*) process with a switch that depends on state and that sets whatever FSM output combinatorially from the curent state (like your read_enable for instance). | 12:45 |
| tnt | Or have the state transitions made in always @(*) comb process and set a "next_state" variable and then in a clocked process you set them in a case that depends on next_state and not on state. | 12:46 |
| tnt | ( Usually I do both ... dpends if I want the signal to be a FF output or a comb signal ... ) | 12:46 |
| Zaba | But in that case, I would still need to have a complex condition such as if (state == READ || (state == IDLE && !read_strobe)) | 12:47 |
| tnt | huh, don't think so. | 12:48 |
| Zaba | If I used a simple switch based on state there would still be the 1-clock delay | 12:48 |
| tnt | https://pastebin.com/BK5CZczb | 12:49 |
| tpb | Title: module test( in wire clk, in wire read_strobe, out reg [3:0] addr, - Pastebin.com (at pastebin.com) | 12:49 |
| tnt | Your example above has 2 clock between read_stobe low and read_enable going high. | 12:50 |
| tnt | What I pasted has 1 clock. | 12:50 |
| Zaba | Alright, yes, in order to have a 1-clock delay in my example, I would need to move read_enable <= 1'b 1 into the "if (!read_strobe)" in the IDLE case | 12:56 |
| *** Guest16 <[email protected]> has quit IRC (Quit: Client closed) | 12:58 | |
| Zaba | (And that is precisely the part that made me unhappy, because it would then need to be duplicated in the READ case) | 12:59 |
| Zaba | Using a separate combinatory block for such cases seems like a good idea though, I need to spend some time wrapping my mind around how the timing works out exactly with it. Thanks! | 12:59 |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has quit IRC (Remote host closed the connection) | 13:12 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has joined #yosys | 13:13 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has joined #yosys | 14:05 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 245 seconds) | 14:09 | |
| *** bjorkintosh <bjorkintosh!~bjork@2600:1700:5400:c80:ed1b:8783:2da7:b322> has joined #yosys | 14:23 | |
| *** bjorkint0sh <bjorkint0sh!~bjork@2600:1700:5400:c80:3a3b:c44a:c92a:2012> has quit IRC (Ping timeout: 245 seconds) | 14:27 | |
| *** emeb_mac <[email protected]> has joined #yosys | 14:28 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has joined #yosys | 14:30 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 252 seconds) | 14:41 | |
| *** citypw <citypw!~citypw@gateway/tor-sasl/citypw> has quit IRC (Ping timeout: 240 seconds) | 14:57 | |
| *** schaeg <schaeg!~anabrid@2a02:3037:303:f23:5f9a:7a3a:3834:aebd> has joined #yosys | 16:11 | |
| *** flokli <flokli!~flokli@2a01:4f8:261:11ce::1> has quit IRC (Quit: WeeChat 4.1.1) | 16:56 | |
| *** flokli <flokli!~flokli@2a01:4f8:261:11ce::1> has joined #yosys | 17:09 | |
| *** Guest25 <[email protected]> has joined #yosys | 18:09 | |
| *** Guest25 <[email protected]> has quit IRC (Client Quit) | 18:09 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has joined #yosys | 19:45 | |
| *** gdd <[email protected]> has joined #yosys | 20:00 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has joined #yosys | 20:06 | |
| *** schaeg_ <schaeg_!~anabrid@2a02:3037:303:f23:5f9a:7a3a:3834:aebd> has joined #yosys | 20:18 | |
| *** schaeg <schaeg!~anabrid@2a02:3037:303:f23:5f9a:7a3a:3834:aebd> has quit IRC (Ping timeout: 276 seconds) | 20:20 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has quit IRC (Ping timeout: 268 seconds) | 21:01 | |
| *** notgull <notgull!~notgull@ec2-50-112-148-23.us-west-2.compute.amazonaws.com> has joined #yosys | 21:23 | |
| *** Guest45 <[email protected]> has joined #yosys | 21:28 | |
| *** Guest45 <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 21:37 | |
| *** Guest31 <Guest31!~Guest31@host86-175-253-228.range86-175.btcentralplus.com> has joined #yosys | 22:16 | |
| *** Guest31 is now known as ali | 22:16 | |
| *** ali is now known as aliali678 | 22:16 | |
| aliali678 | I'm trying to use oss-cad with a tangnano9k, does anyone know of a "known working" release? | 22:18 |
| aliali678 | Specifically gowin_pack fails with "type object is not subscriptable" on the latest version no matter what I do. | 22:19 |
| *** e_ter <[email protected]> has joined #yosys | 22:54 | |
| *** eater <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 22:54 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Quit: Leaving) | 23:00 | |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:23 | |
| *** nonchip <[email protected]> has joined #yosys | 23:23 | |
| *** aliali678 <aliali678!~Guest31@host86-175-253-228.range86-175.btcentralplus.com> has quit IRC (Quit: Client closed) | 23:24 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!