nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #yosys
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #yosys
citypw has joined #yosys
notgull has quit [Ping timeout: 276 seconds]
Guest16 has joined #yosys
notgull has joined #yosys
notgull has quit [Ping timeout: 252 seconds]
citypw has quit [Ping timeout: 240 seconds]
emeb_mac has quit [Quit: Leaving.]
citypw has joined #yosys
FL4SHK has quit [Ping timeout: 260 seconds]
FL4SHK has joined #yosys
<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
<Zaba>
g the code to drive the outputs into multiple states?
<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 ....
<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.
<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?
<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).
<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.
<tnt>
( Usually I do both ... dpends if I want the signal to be a FF output or a comb signal ... )
<Zaba>
But in that case, I would still need to have a complex condition such as if (state == READ || (state == IDLE && !read_strobe))
<tnt>
huh, don't think so.
<Zaba>
If I used a simple switch based on state there would still be the 1-clock delay
<tpb>
Title: module test( in wire clk, in wire read_strobe, out reg [3:0] addr, - Pastebin.com (at pastebin.com)
<tnt>
Your example above has 2 clock between read_stobe low and read_enable going high.
<tnt>
What I pasted has 1 clock.
<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
Guest16 has quit [Quit: Client closed]
<Zaba>
(And that is precisely the part that made me unhappy, because it would then need to be duplicated in the READ case)
<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!
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
notgull has joined #yosys
notgull has quit [Ping timeout: 245 seconds]
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
bjorkintosh has joined #yosys
bjorkint0sh has quit [Ping timeout: 245 seconds]
emeb_mac has joined #yosys
notgull has joined #yosys
notgull has quit [Ping timeout: 252 seconds]
citypw has quit [Ping timeout: 240 seconds]
schaeg has joined #yosys
flokli has quit [Quit: WeeChat 4.1.1]
flokli has joined #yosys
Guest25 has joined #yosys
Guest25 has quit [Client Quit]
kristianpaul has joined #yosys
gdd has joined #yosys
notgull has joined #yosys
schaeg_ has joined #yosys
schaeg has quit [Ping timeout: 276 seconds]
notgull has quit [Ping timeout: 268 seconds]
notgull has joined #yosys
Guest45 has joined #yosys
Guest45 has quit [Ping timeout: 250 seconds]
Guest31 has joined #yosys
Guest31 is now known as ali
ali is now known as aliali678
<aliali678>
I'm trying to use oss-cad with a tangnano9k, does anyone know of a "known working" release?
<aliali678>
Specifically gowin_pack fails with "type object is not subscriptable" on the latest version no matter what I do.